movilidad/tiempo-real
Pickando
Prueba técnica de movilidad local en Rust: interfaz compilada a WebAssembly, servidor asíncrono y un modelo de relevancia que ordena las rutas por lo cerca, lo alineadas y lo oportunas que son.
entregado · 2026
el problema
Emparejar a quien va y a quien pide no es buscar «lo más cercano»: dos personas a cien metros pueden ir en sentidos opuestos, y una ruta que sale en tres horas no vale lo mismo que una que sale ya. Hace falta ordenar por varios criterios a la vez, no filtrar por uno.
qué hice
- Relevancia ponderada en vez de filtros encadenados: distancia 0,5, alineación de rumbo 0,3 y ventana temporal 0,2, con los pesos documentados y pensados para ajustarse contra la conversión real. Solo la distancia descarta; lo demás ordena.
- El prefiltro por geohash se RETIRÓ tras medir que producía falsos negativos en los bordes de celda —una ruta a 839 m compartía solo tres caracteres y desaparecía— y que el barrido completo tardaba menos de 100 µs a esta escala. La columna se conserva para expandir por celdas vecinas cuando el volumen lo pida.
- WebSocket bidireccional con difusión sobre `tokio::sync::broadcast`, para que un cambio de estado llegue a todos los interesados sin que nadie pregunte en bucle.
- Interfaz y servidor en el mismo lenguaje: Dioxus compila a WebAssembly y Axum corre sobre Tokio. El APK de Android es un contenedor WebView, no un build nativo, y así está decidido y escrito en el repositorio.
- Contenedor multietapa con usuario sin privilegios, y CI que en cada cambio pasa formato, clippy con los avisos como errores, auditoría de dependencias y pruebas.
stack
- Rust
- Dioxus
- WebAssembly
- Axum
- Tokio
- WebSocket
- Docker
siguiente
¿Quieres algo parecido?