Apple Podcast (iTunes) | iVoox | Spotify | Suscríbete al podcast

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!

¿Quieres ser mejor desarrollador?

Escrito por Dani

Soy programador web, podcaster y formador. Especialista en frameworks basados en PHP, aunque mis favoritos son los microframeworks en varios lenguajes (Python, Javascript) en los que constuyes de verdad a la medida la aplicación de tus sueños. Aquí puedes conocerme mejor.
comments powered by Disqus