Web Reactiva

WR 118: Buenos propósitos para un "side project"

Lo que he aprendido en los últimos meses para hacer un proyecto viable.

Escúchalo también en Spotify | Apple Podcasts | Google Podcasts | iVoox

Cada domingo por la mañana puedes tener en tu bandeja de entrada un newsletter único sobre desarrollo y programación.

Hablándote de aspectos técnicos (y también emocionales) en castellano.

Apúntate gratis en /newsletter.

Ejemplos de ‘side project’

Hay un par de ejemplos que te cuento en el episodio.

Uno ya está publicado, es el ranking de podcasts de tecnología.

El otro, en ejecución, es la plataforma para compartir contadores festivos. Es el protagonista de los LiveCoding de la Zona Premium.

Ambos son sencillos, pero me llevaron en solitario a enfrentarme a mí mismo y a cuestiones tecnológicas que eran desconocidas en el momento de empezar.

Un sólo factor grande de riesgo

Todo depende de lo que ya sabes. Y de lo que te guste el riesgo.

Reconozco que me admiro la valentía, siempre que esté calculada.

El asunto es que uno no quiere darse un tortazo. Arrebatar tiempo a la vida para construir un proyecto y luego no llegar a ninguna parte es frustrante.

No seas como Salomon Andrée, que tomo tantos riesgos que contó su aventura luego desde los diarios.

Historias de usuario

Escribir buenas historias de usuario es como un lugar seguro al que acudir para tener orden.

Sin ser un experto en agilismo es una buena forma de materializar y compartimentar los deseos que puede tener un usuario cuando se enfrenta a tu aplicación.

Te dejo algunos enlaces para profundizar sobre el tema:

Cíñete al plan

Es fácil escaparse de la responsabilidad de avanzar centrándose en otras cosas importantes pero no esenciales como las herramientas de trabajo.

También puedes caer en el rabbit hole o en el YAGNI.

Es importante volver a “casa” y evaluar estás en el camino correcto.

Lo ideal es que marques los tiempos suficientes para no desprenderte del proyecto, pero tampoco robarle más tiempo a tu vida. Si es sencillo quizás puedas trabajar cada semana o 15 días.

Si es más complejo, necesitarás una mejor planificación.

Elegir el stack tecnológico

Sigue vigente el principio del “único factor grande de riesgo”.

En el caso del ejemplo que te cuento en el episodio, ese camino más complicado lo tomo utilizando una arquitectura desacoplada como la que ves en esta captura.

Para la parte del backend me quedo con PHP.

Es una herramienta en la que tengo un conocimiento más sólido. Eso sí, con el firme propósito de no quedarme en lo de siempre, desciendo hasta un microframework para trabajar desde abajo e ir creciendo.

El elegido es Slim.

Hablo bastante de los estándares PHP.

En el frontend considero que tengo que seguir profundizando en la potencia de VueJS. Aún me queda, pero antes de dar el salto a React quiero ser capaz de escribir buen código de forma más “automática”.

Los otros elementos de esta arquitectura irán llegando. Lo cuento en detalle en el episodio WRP 48.

¡Nos escuchamos el próximo martes!

12 recursos para developers cada domingo en tu bandeja de entrada

Además de ofertas de empleo para developers, recibirás ideas para nuevos proyectos, trucos para mejorar tu futuro profesional y una pizquita de humor útil para el resto de la semana. Gratis.