Las race conditions, o condiciones de carrera, representan una vulnerabilidad que surge cuando el comportamiento de un sistema depende del orden o la sincronización de múltiples operaciones concurrentes. Esto ocurre cuando el servidor procesa peticiones simultáneamente sin implementar los mecanismos de protección adecuados (safeguards), lo que puede derivar en inconsistencias, errores inesperados o incluso fallos críticos en la seguridad del sistema.
ISecAuditors
Pues eso, segunda parte de los proyectillos pequeños que hacemos para no morirnos de la rutina en nuestro trabajo. Si no has leído la parte anterior, te la dejo aquí por si te interesa.
Como contaba en el post anterior, estos proyectos nos ayudan mucho a mantenernos al día tecnológicamente o para matar el gusanillo de probar esas cosas nuevas que nos hacen recordar por qué estamos en este ámbito. La gracia de estos pequeños proyectos es que los solemos empezar desde cero; un Green field project qué se llama. Esto nos quita limitaciones de proyectos existentes en los que tengamos que lidiar con mil cosas antes de ponernos de verdad en faena.
Hasta aquí todo bien, ¿no? El problema viene en que estos cambios pocas veces se aplican en proyectos existentes a no ser que todo el equipo o empresa reme a favor de implementarlos. Las empresas no pueden parar todo su desarrollo simplemente por mantener la base de código actualizada y con las novedades del sector. Si la empresa o producto depende mucho de una tecnología o framework concreto, estará en un punto en el que cualquier cambio será peligroso y se dejará de lado.
Por otro lado, en el post anterior comentaba la necesidad que nos imponía la sociedad de producir cada vez más, lo que conlleva que nuestros cambios siempre tengan que estar orientados a sacar rédito de ello. Las pequeñas pruebas aisladas no nos van a producir ningún beneficio a nivel productivo, cosa que ya hemos comentado que no está mal, pero... ¿No estaría bien que por el camino pudiéramos ir mejorando el producto, ya sea personal o de la empresa?
Yo, como creo que cualquier desarrollador de aplicaciones móviles, tiene o ha tenido decenas o incluso cientos de ideas con las que se haría rico si tuviera tiempo para desarrollarlas. O al menos eso es lo que está en nuestras cabezas. La realidad es que sacar una app a producción conlleva un tiempo considerable y cuando finalmente sacas el MVP, te queda un largo camino de mejoras y resolución de problemas por delante.
Tengo más de 10 años de experiencia en empezar proyectos pero tengo muy pocos en terminarlos. Todas las pruebas que realizo las suelo hacer sobre una nueva idea por si me da tiempo a irla mejorando. De esta forma intento unir los dos mundos de seguir probando cosas nuevas y de poder generar algo a cambio del esfuerzo invertido. Yo creo que puedo haber empezado unas 20 o 30 aplicaciones diferentes (no pretendo ser un flipao pero tampoco estoy exagerando) de las cuales han llegado a estar publicadas en la play store (al menos en algún momento) unas 7. Para ser honesto conmigo mismo, conociéndome un poco, son bastantes más de las que me esperaba echando las cuentas. Sin embargo, aqui no he incluido los pequeños proyectos para probar algo sin una idea que la sustente ya que son muchos más.
Aunque el ratio está mejor de lo que me esperaba, hay un problema bastante importante que no me permite mejorar y sacar más aplicaciones a producción. Bueno, en realidad son varios así que vamos a ir desgranándolos poco a poco. Para no abrumaros, dejo este post aquí y os dejo los detalles en nuevas entregas.
Nos vemos!