yeiniel

Por qué usar inject() en lugar de inyección por constructor puede perjudicar tu proyecto Angular Recientemente, he observado una tendencia creciente en la comunidad Angular: el abandono de la inyección de dependencias por constructor en favor de la función `inject()`. Aunque esta función tiene casos de uso legítimos, su adopción generalizada como reemplazo del patrón clásico introduce problemas sutiles pero significativos en la mantenibilidad y testabilidad del código.  El atractivo de inject() La función `inject()` fue introducida en Angular 14 como una alternativa para obtener dependencias fuera del contexto del constructor. Su sintaxis es innegablemente concisa: @Component({...}) export class UserComponent { private userService = inject(UserService); private router = inject(Router); } Comparado con el enfoque tradicional: @Component({...}) export class UserComponent { constructor( private userService: UserService, private router: Router ) {} } L...

En la actualidad trabajo como ingeniero de software para mi cliente actual. En este contexto, tengo acceso a los modelos LLM más recientes de distintos proveedores (tres, concretamente). En este post quiero compartir una retrospectiva, a la fecha, sobre cómo ha sido esa experiencia.  Para comenzar, debo aclarar que en muy pocas tareas en las que he utilizado modelos LLM he considerado aceptable permitir que el modelo realice acciones sin una revisión de mi parte. Es decir, en contadas ocasiones he hecho vibe coding. Mi lógica es simple: no puedo aceptar algo que no esté dispuesto a mantener. La experiencia de otros puede variar, y no afirmo que el vibe coding no tenga casos de uso válidos.  Respecto a cómo han cambiado las cosas, cabe mencionar que las soluciones con acceso al proyecto completo y a herramientas han sido una evolución agradable frente a las versiones iniciales que únicamente autocompletan líneas de código. El aumento del contexto disponible ha sido, sin duda, ...