[Proyecto Personal]: Sonificafy

Recientemente he lanzado Sonificafy. Un side-project que ideé hace ahora un año y que tenía muchas ganas de construir.

Es un site que transforma cualquier URL pública en sonido, para conocer de una forma divertida cómo suena tu web ✨

Objetivo

Materializar una idea y disfrutar con el proceso.

En esta página sobre el proyecto explico mi motivación, los objetivos y el reto que ha supuesto pero, en resumen, buscaba construir algo de principio a fin pero es que además por el camino he encontrado muchas cosas valiosas, una de ellas ha sido poder explorar un montón de roles diferentes.

He tomado todas las decisiones posibles como project manager, product owner, visual designer (UX/UI), front-end, back-end y devops. Me he divertido mucho porque en el día a día no tengo la posibilidad de saltar entre roles o responsabilidades. Es uno de los puntos fuertes de los side-projects.

Cómo empezó todo

Lo primero es explicar que me flipa el espacio, la ciencia ficción y la idea de la sonificación.

Descubrí que NASA tenía un canal en SoundCloud con pistas de audio sobre el sonido de planetas y nebulosas (también en YouTube) lo cual no podía ser porque si el sonido no puede propagarse en el espacio no podrías oír nada, aunque se me hacía rara la idea de estar flotando delante de Júpiter y sólo escuchar silencio o el sonido de tu respiración dentro del casco como mucho.

Ocurre que NASA convierte los datos que obtiene como por ejemplo pulsos electromagnéticos en sonido. Desconozco el nivel de procesamiento porque los armónicos de algunas partes de estas pistas son tremendas 🤘

Así que investigué un poco sobre el proceso y aprendí lo básico sobre su funcionamiento y me pregunté si podría hacer lo mismo con HTML. Si cualquier entrada podría convertirse en audio.

Planificación

Parecía fácil:

1. Hacer el script de Python para la sonificación
2. Construir el back-end
3. Diseñar el front-end
4. Construir el front-end
5. Integrar front-end y back-end
6. Preparar la infraestructura
7. Desplegar 🚀

Tecnología

• Front-end (React + Vite + PostCSS): Como front-end, fue fácil elegir el stack para esta parte del proyecto. Quería la flexibilidad de React pero mantenerlo sencillo.

• Back-end (Node.js + Express): Aunque no es el ámbito en el que mayor conocimiento tengo, sí que puedo manejarme así que opté por la solución que me era más familiar.

• Back-end (Python): Al inicio busqué librerías de JavaScript con las que replicar el proceso pero entendí que lo más apropiado era utilizar Python y NumPy y SciPy así que estaba en un pequeño aprieto porque no tenía conocimientos suficientes para llevarlo a cabo.

• Back-end / DevOps (Docker): Tampoco era parte de mi plan inicial pero después de valorar diferentes enfoques opté por dockerizar esta parte y mantener todo el back-end unido.

• DevOps (Render + Fly.io): Escogí Render para el front-end porque conocía la plataforma y sabía que un static site sería gratuito y Fly.io para el back-end porque me convenció más que Railway

IA

Ha jugado un papel muy importante porque no habría podido llevar a cabo este proyecto -o al menos no en el mismo tiempo- de no haberla utilizado, porque necesitaba ayuda con Python y Docker.

Elegí Claude como compañero experimentado y me resultó muy fácil trabajar con él porque sabía describir con detalle lo que buscaba y orientar sus respuestas y refinar el resultado.

Poco a poco, los profesionales que conforman esta industria han ido posicionándose a favor o en contra de usarla desde el surgimiento de ChatGPT, y las opiniones oscilan entre el “nos quitarán el trabajo” hasta “es una herramienta que hay que aprender a usar”. Yo he ido adoptándola poco a poco, evaluando de qué manera me podría ayudar o aportar valor y siento que ya tengo mi propia opinión y no es ni una ni la otra sino que veo que es una herramienta que liberará nuestra creatividad, que nos dará alas, y creo que podemos esperar próximamente el florecimiento de muchas ideas extrañas, buenas y malas, que hasta ahora morían antes de nacer porque ¿quién puede abarcar todos estos roles profesionales? ¿quién puede montar un equipo para siquiera validar una idea? Estamos en un momento en el que tienes la posibilidad de convertirte en jefe de proyecto y dirigir tu propio equipo.

¿Sustituirá entonces una sola persona a un equipo entero? No lo creo. Creo que seguirán habiendo profesionales especializados que podrán delegar tareas más o menos repetitivas, y que surgirán nuevos roles híbridos porque podremos abarcar más aunque con una visión más superficial de cada área.

Creo que el futuro inminente será muy interesante. Yo por lo menos no puedo parar de pensar en qué es lo siguiente que voy a hacer y en recuperar aquellas cosas que años atrás se me caían (morían antes de nacer) porque igual no tenía el conocimiento sobre persistencia que necesitaba o cómo desplegar mi back-end.

Side-projects

Hay mucho escrito sobre lo positivo de este tipo de proyectos y alguno de los beneficios ya los he comentado más arriba pero creo que es importante destacar que si bien son un soplo de aire fresco, no hay que sentirse presionados con el mantra “hay que hacer, hay que hacer”. Sencillamente puede que esta visión no vaya contigo y está bien que sea así.

Cosas qué he aprendido

• Algún concepto musical y otros “detalles de su implementación”
• Sobre Python como lenguaje de programación y su ecosistema
• Algo sobre Docker (aunque tengo mucho aún por conocer)
• Fly.io como plataforma, con planes gratuitos muy generosos
• Que los entornos deberían estar montados y disponibles desde el principio del desarrollo, que luego llegan las sorpresas

Recursos

• Repositorio Back-end
• Repositorio Front-end