Es común cuando queremos hacer algo por primera vez, buscar tutoriales que nos enseñen a hacer eso que necesitamos. Y está bien, de alguna forma hay que aprender, el problema está en cómo consumimos los tutoriales. El año pasado me decidí por mejorar todo el sistema de usuarios de mi plataforma. Básicamente creación de cuentas, guardar y encriptar contraseñas, recuperación de contraseñas, etc. Cuando empecé este proyecto, yo había implementado mi propio sistema, según como yo creía en ese momento, que tenía que manejarse la seguridad. Hasta que me decidí por hacer las cosas como corresponde y me puse a investigar algo que viene "nativo" en .NET que es ASP Identity Core. Identity Core es un framework de Microsoft que provee una capa de funcionalidades, ya re contra probadas, para todo lo referente a manejo de identidad, autenticación y autorización. De esta forma no tenemos que reinventar la rueda. El problema está, que me puse a ver la documentación. Y luego de la documentación me puse a ver un video. Pero no encontraba precisamente un video que explique el mismo caso que yo tenía, que era una aplicación web en asp.net, con una base de datos en MySQL SIN usar Entity Framework. Y como no encontraba un video, me puse a ver otro video, y después otro video, y después otro video y después me dí cuenta que ya había pasado más de 1 mes, todavía no entendía como aplicar Identity Core en mi aplicación, se me estaba pasando el tiempo, y ya andaba todo despeinado por mi casa super estresado. ¿Te das cuenta el problema? Y mirá que llevo muchos años picando código y haciendo proyectos y programas y sistemas y etc. O sea que es fácil caer en este problema de mirar tutoriales y videos. ¿Cómo lo solucioné? 1. Dejé de ver tutoriales en YouTube 2. Me hice un proyecto nuevo en asp.net, super básico, limpio, sin nada de mi lógica de negocio 3. Me puse a seguir la documentación oficial que hay para implementar lo mas básico de identity core con Entity Framework. 4. Me puse a probar y de a poco entender y ver cómo funcionaba el sistema. Depurando con tranquilidad. 5. Una vez que entendí como era la cosa, me puse a implementar eso mismo en mi aplicación.

El sábado pasado estaba en una llamada con una persona que está en mi mentoría (mentorías de prueba que estoy haciendo para pensar formatos y un sistema efectivo que luego pueda aplicar con muchas más personas) y me comentó que uno de los mayores problemas que tiene y que le da bastante inseguridad, es trabajar en requerimientos de proyectos cuyo código no conoce y en donde tampoco tuvo una participación directa. Algo muy común en empresas del tipo Software Factory (empresas que se dedican a crear software para abarcar múltiples negocios). Yo sé lo que se siente, porque de hecho mi primer trabajo fue en la misma empresa donde él está ahora. Mi recomendación para esto es que busquen repositorios públicos con código open source, de cualquier cosa, y se pongan a leer y traten de entender algo, traten de aportar, de solucionar algún problema que ese código tenga. Eso les va a dar una práctica y un entrenamiento muy bueno a la hora de encarar proyectos que no conocen. Les va a agilizar el entendimiento de código y van a ganar una experiencia y un instinto que no se gana de otra forma. Les recomiendo que lo prueben y me cuenten sus resultados! Buen miércoles

El otro día estaba rastreando logs en producción del sistema de la empresa donde trabajo, para ver si encontraba algún error para corregir (y así justificar el sueldo 🤫) Encontré uno que se generaba en varios lugares, así que me puse a revisar. El problema era que habían diseñado una clase de utilidad (UtilsService) con funciones comunes, y dentro de esta clase había varias dependencias con otras clases. Estas dependencias estaban creadas por Inyección de Dependencias (Hay un video acá en la comunidad que habla sobre la Inversión de Dependencias, te va a servir si no conocés este término). PERO, había una dependencia que la crearon a mano, pasandola por parámetros, porque se ve que les daba fiaca acomodar todos los servicios a lo largo de todo el sistema. Me puse a tratar de corregir eso para evitar refactorizar todo (ya que implica un cambio grande), pero mientras trabajaba, tenía la sensación que le estaba dando mucha vuelta y que mi solución era muy rebuscada. Lo mejor era hacer las cosas como corresponde y refactorizar. Yo tenía el presentimiento que tenía que hacerlo bien, estaba sintiendo que daba muchas vueltas y era rebuscada mi solución. Lo mejor era hacer las cosas como corresponde. Conclusión: Muchas veces va a pasar que sentís que la solución que estás aplicando o buscando para resolver un problema es engorrosa. Y si sentís eso, probablemente tenés razón. Mejor tomate tu tiempo, analizá bien las cosas y hacé que el sistema funcione como tiene que ser. Aunque te tome el doble de tiempo ahora, te va a ahorrar muchos dolores de cabeza en el futuro. ¡Buen comienzo de semana!