Desde marzo me da vueltas una app para llevar el marcador de los partidos de pádel. La idea salió de una charla con un amigo. La planeé, la dejé y, cada tanto, volvía. Hace unas noches volvió otra vez, por otra puerta, y esta vez no la solté hasta tenerla andando.
Marzo: el marcador por voz
El problema de base es simple: cuando jugás, no tenés nada encima, ni querés tenerlo. Mi amigo propuso resolverlo por voz, con palabras clave, y yo me sumé a pensar cómo hacerlo.
El plan era transcribir el audio con Whisper (abre en otra pestaña) en el teléfono, o con un servicio en la nube, y darle a cada equipo sus palabras clave. Un cooldown de 30 segundos evitaba que la misma palabra sumara dos veces, y cada equipo tenía su propio sonido para confirmar el punto. Llegué a armar la arquitectura y el planning, pero no a escribir código: en ese momento estaba con otro proyecto.
Igual, siempre le vi un inconveniente. Si fallaba o detectaba mal algo, había que ir a mirar el teléfono de todos modos, que era justo lo que queríamos evitar. A eso se sumaba la complejidad de armar algo útil y eficaz. Nunca encontré una solución elegante para esos errores, y eso me echaba para atrás.
Sacar el problema de raíz
Muchas veces nos paramos a buscar soluciones a un problema, en vez de sacar el problema de raíz. Con el reconocimiento de voz me pasaba eso: resolvía lo de no tener el teléfono, pero abría otros problemas. Me ponía a analizar cómo corregirlos, y la cosa no paraba de crecer: alias para cada palabra, umbrales de confianza, alguien a cargo del teléfono, pruebas en una cancha con ruido. Y en la lista de “algún día” ya había un modo torneo.
La salida apareció mientras scrolleaba en X: vi en un tweet un contador autoadhesivo para el borde de la pala. Me hizo click. Si el marcador podía ir en la pala, también podía ir en mi muñeca, donde ya llevo puesta la pulsera en cada partido. Ahí saqué el sonido como opción, y con eso saqué el problema de raíz. Recién entonces pude enfocarme en soluciones que ni había pensado, porque hasta ese momento tenía el esfuerzo puesto del lado equivocado.
Por eso creo que una idea merece volver si te seguís encontrando con el problema. Tal vez la implementación no fue buena al principio, o todavía no alcanzaba.
La band ya es una cancha
La pulsera es una Xiaomi Smart Band 10, bastante más simple que un reloj con Android. Mejor todavía: al fin y al cabo, es una banda deportiva, y ahora mide un deporte más. Como yo quiero.
Esa misma madrugada me puse a averiguar si había un marketplace o si podía armar mis propias apps. Marketplace no hay: Xiaomi no tiene una forma pública de instalar apps de terceros. Pero las apps de la band se escriben en JS, como quick apps de Xiaomi Vela (abre en otra pestaña), y aiot-toolkit (abre en otra pestaña) las compila en un paquete .rpk. MiBand Hack (abre en otra pestaña) lo instala en la band por Bluetooth, desde el navegador. Con eso resuelto, el resto fue simple.
Mirándola, me di cuenta de que la pantalla tiene la misma proporción que una cancha. Así que la dividí en dos: arriba, los rivales, y abajo, nosotros. Un tap o un swipe a la derecha suma un punto y un swipe a la izquierda lo resta, para el equipo de la mitad donde lo hagas.
Después le sumé las reglas (15, 30, 40, ventaja o punto de oro, sets a 6 y tie-break), el contador de games, quién tiene el saque, un historial para corregir errores y la opción de mantener la pantalla encendida. Para no tener que mirarla, la band vibra corto con cada punto y largo cuando un punto cierra un game.
Lo del historial es lo que más me gusta. En marzo, el modelo de datos tenía partidos, equipos, palabras clave y eventos de puntaje. En la band, el partido es la secuencia de quién ganó cada punto, y el marcador sale de volver a reproducirla. Deshacer un punto es editar esa secuencia, así que la cuenta no se puede descuadrar.
Como todo es JS, me resulta fácil seguir el código, proponer estructuras y sugerir cambios. Hubo un rato de charla con Claude (abre en otra pestaña) para los estilos, una prueba rápida, sin mucho detalle, para ver si la idea funcionaba, y unas cuantas vueltas de UI y UX. La estructura del proyecto y el arnés de tests salen de Calc+ (abre en otra pestaña), de Ari Wilson.
Queda probarla, encontrar errores y mejoras, y seguir ajustándola.
Una hora para ahorrar 45 minutos
Ideas uno siempre tiene. O mejor dicho, problemas uno siempre se encuentra. Yo siempre fui de preferir perder una hora armando un script que me ahorre 45 minutos de trabajo repetitivo. La cuenta no cierra, ya sé: la primera vez pierdo 15 minutos. Pero aprendo, me divierto y, la segunda vez que tengo que hacer lo mismo, ya lo tengo. Ahí empieza a cerrar.
Me pasó hace unos meses con Goodreads (abre en otra pestaña). Tiene muchas cosas que nunca me gustaron, pero me era útil. Hasta que quise anotar los libros que leemos mi hija y yo: la app no permite perfiles, y mi hija es chica, así que no quería darle su propio teléfono. Entonces me propuse hacer una app parecida, para uso personal, y de paso corregirle lo que no me gusta y sumarle lo que le falta.
Me puse a investigar cómo hacerla nativa en Android, y la terminé haciendo: importa todo mi historial de Goodreads y ya anda en local. Le faltan unas cuantas madrugadas para tomar forma, y no es un producto para lanzar. Aun así, me resuelve un problema y me divierte armarla. Pero esa es una historia para otro post.
Lo que cambió es la distancia entre la idea y el boceto. Hoy la carrera es más corta y la meta siempre está a la vista, incluso en terrenos que uno no conoce, como me pasó con Vela. Validar una idea es cada vez más simple.
El proceso, en cambio, es el mismo que sigo con un cliente y su problema: pensar una arquitectura rápida y simple, sin enroscarse con estructuras complejas, y poder corregir el rumbo a tiempo.
Rápido no es desprolijo
Ahora, rápido != desprolijo, pero tampoco tiene que ser perfecto. Lo importante es no enroscarse en los detalles que llevan mucho: el 20% del trabajo que resuelve el 80% del problema, como dice la ley de Pareto. Y a eso, sumarle una capa mini de estética. Me habré pasado a la programación, pero el diseñador vive adentro y no lo puedo evitar. Por eso la app usa naranja y azul, que se distinguen aun con daltonismo rojo-verde, sobre fondo negro, que en una pantalla AMOLED gasta menos batería.
Entre ver el tweet, averiguar, planear y moldear algo, en dos horas, dos y media como mucho, tenía la app empaquetada, transferida a la pulsera y publicada en GitHub (abre en otra pestaña), abierta a la comunidad.
Si tenés una band, podés bajarla desde Releases (abre en otra pestaña), y en el README están los pasos para instalarla. Solo la probé en mi Band 10, así que en otros modelos puede que no ande. Si la probás y algo falla, abrí un issue (abre en otra pestaña). O mejor todavía: corregilo y mandá un PR.
Perderle el miedo a probar
Problemas chicos del día a día tenemos todos. Los que somos developers, o los que pensamos de un modo lógico, tenemos una pequeña ventaja para resolverlos, y vale la pena exprimirla. Se puede armar algo rápido, aprovechar la velocidad de la IA, salir a probarlo y, si hay algo ahí, trabajarlo y pulirlo hasta que sea sólido y útil.
A mi marcador todavía le falta la prueba de verdad: un partido. Pero al menos esta vez, la idea volvió sabiendo qué problema tiene que resolver.