{
  "id": 7606808,
  "title": "Tres proyectos, tres formas distintas de romperme la cabeza",
  "url": "https://urgent.news/2026/09/15/tres-proyectos-tres-formas-distintas-de-romperme-la-cabeza",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-15T18:45:02.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/giusseppemarinelly/tres-proyectos-tres-formas-distintas-de-romperme-la-cabeza-3k6k"
  },
  "original_language": "es",
  "account": "The author, a student of Computer Engineering, built three distinct projects this year that taught them different lessons. Each project revealed an unexpected challenge beyond the initial expectations.\n\n1. The first project involved reading an industrial scale via serial port to replace the weighing software of a plant's trucks. The author, coming from web development, initially thought they could request the weight like an HTTP request. However, the scale emits continuous frames through the serial port, not waiting for requests and at its own pace. This led to an architecture consisting of a process reading the port continuously, a FastAPI backend that retransmits via WebSocket, and two desktop stations displaying the same weight at the same moment. The true challenge was not the hardware but the model of states. The weighing process passes through stages: in_planta → pendiente_aprobacion → aprobado/rechazado → completado. A completed record cannot be altered and contains financial consequences. The author designed the schema assuming someone might try to edit it, with the system correctly preventing it. They implemented 14 tables in PostgreSQL, migrations with Alembic, and tests with Pytest on isolated SQLite. This was not optional: a bug that changes a facturable weight goes unnoticed in development and is discovered in a bill. The lessons learned were that integrating hardware removes assumptions made in web development, such as data availability, retryability, and state living in the database.\n\n2. The second project was a social app called \"Epa\" that allowed university students to organize events on campus. While it seemed like a simple CRUD app, two innocent functions turned out to be delicate: location sharing. Showing user locations is useful but also constitutes surveillance. The author implemented it as an opt-in feature with automatic expiration, meaning users don't need to remember to turn it off. The app sends location requests via a temporary opt-in and expiries automatically. The server handles file delivery, not the app. The author learned that difficult decisions in social apps are rarely technical; they are about what permissions you grant one user over another's data.\n\n3. The third project was a Progressive Web App (PWA) called \"BeatWave\" that played music from the author's own Navidrome server without requiring an internet connection. The author initially thought offline-first meant caching data. However, in practice, the challenge was deciding what happens when the network comes back online, when the cache and server are out of sync, or when the user closes the app mid-download. They also integrated the Media Session API, which controls app controls during the screen lock, showing album and title information. The author learned that offline-first is not just about caching; it's about accepting that your app will live in a constant intermediate state between connected and disconnected.\n\nAll three projects taught the author that the real problem often lies elsewhere than initially thought. For the hardware integration, it was the data model. For the social app, it was privacy. For the PWA music player, it was synchronization.",
  "summary": "Publicado originalmente en mi blog . Soy estudiante de Ingeniería en Computación y desarrollador. Este año construí tres cosas muy distintas entre sí, y cada una me obligó a desaprender algo. Las dejo aquí porque los problemas interesantes no siempre fueron los que esperaba. 1. Leer una báscula industrial por puerto serie El encargo era sustituir el software de pesaje de camiones de una planta.…",
  "key_points": [
    "First project taught hardware integration challenges beyond web development assumptions",
    "Second project revealed privacy concerns as key decision in social app development",
    "Third project discovered synchronization issues in offline-first Progressive Web App"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}