Descubre artículos sobre inteligencia artificial, desarrollo de aplicaciones a medida y consejos prácticos de ingeniería de software. Aprende cómo la tecnología puede potenciar tus proyectos.

Los N clientes principales que concentraron la mitad de las ventas ese año

Para identificar los clientes principales de 1998 se sigue un método sencillo y reproducible: agrupar el registro de contratos por cliente, sumar el importe total por cliente, ordenar los totales de mayor a menor, calcular la mitad del volumen total de ventas y acumular los totales ordenados hasta que la suma acumulada supere la mitad. Los clientes incluidos en esa acumulación son los clientes principales de 1998.

Pasos prácticos resumidos: 1 Agrupar por cliente y sumar importes 2 Ordenar por total descendente 3 Calcular mitad del total de ventas 4 Acumular desde el mayor hasta superar la mitad 5 Los clientes acumulados son los principales

Este enfoque se puede implementar con consultas SQL, scripts en Python o herramientas de análisis de datos para obtener rápidamente la lista de clientes que concentraron el 50 por ciento de las ventas en 1998. En la práctica conviene validar las asociaciones de claves foráneas entre la tabla de contratos y la tabla de clientes, y revisar registros atípicos que puedan distorsionar la clasificación.

Estás invirtiendo horas en tutoriales. Has guardado mil artículos sobre el mejor framework de JavaScript. Te preocupa no saber suficientes algoritmos. Sientes que corres sin avanzar. Suena familiar. Todo el mundo te dirá que el error es no practicar lo suficiente o no aprender el lenguaje correcto. Están equivocados. Esos son síntomas. El error número uno de los principiantes es formarse con un conjunto de habilidades de libro de texto en lugar de uno práctico. Aprendes para aprobar un examen, no para resolver un problema. Acumulas información en lugar de desarrollar intuición.

Esto se traduce en un hábito letal: el infierno de los tutoriales. ¿Qué es el infierno de los tutoriales? Es la sensación cómoda y engañosamente productiva de seguir un video o artículo, teclear el código que te indican y terminar con un proyecto que funciona. Te parece que has aprendido. Pero cuando intentas crear algo por tu cuenta, tu mente se queda en blanco. Por qué ocurre esto. Porque has practicado replicar, no crear.

Señales claras de que estás en el infierno de los tutoriales: He terminado el curso pero no sé cómo empezar mi propio proyecto. Puedo seguir el tutorial pero si me pides que lo haga desde cero me pierdo. Entiendo los conceptos cuando me los explican pero no puedo aplicarlos solo. Esto es dañino porque mata la confianza, es increíblemente ineficiente y te enseña a depender siempre del experto. En vez de aprender a descomponer problemas y buscar soluciones concretas, tu primer instinto es buscar otro tutorial.

Cómo escapar del infierno de los tutoriales. La buena noticia es que escapar es más sencillo de lo que imaginas. No necesitas otro curso, necesitas un cambio de estrategia.

1 La regla 80 20 del aprendizaje Deja de intentar aprenderlo todo antes de construir. Solo necesitas el 20 por ciento del lenguaje para crear el 80 por ciento de los proyectos que quieres empezar. Qué hacer. Aprende lo básico absoluto variables funciones bucles condicionales y empieza inmediatamente un proyecto. El resto llegará justo a tiempo cuando necesites resolver un problema concreto. Así se fija el conocimiento.

2 El truco con los tutoriales Nunca sigas un tutorial tal cual. Rompe el tutorial y arréglalo. Qué hacer. Tras acabar un proyecto de tutorial cambia totalmente el estilo añade una funcionalidad pequeña que no incluyeron rompe el código a propósito y usa las habilidades de depuración que has evitado para entender por qué falla. Intenta reconstruir el mismo proyecto un día después sin mirar el video. Este hábito transforma el aprendizaje pasivo en creación activa.

3 Construye tu propia cosa pequeña ahora No necesitas una idea grandiosa necesitas un proyecto que puedas terminar. Deja de buscar la próxima gran red social. Crea lo más pequeño y simple que puedas imaginar una calculadora una página de portafolio personal solo con HTML y CSS una lista de tareas que funcione en el navegador un programa que consulte una API y muestre el clima. El objetivo no es impresionar sino pasar de archivo en blanco a producto terminado por tu cuenta. Esa sensación de logro es combustible para el siguiente proyecto.

Acepta la lucha ese es el secreto. La pantalla en blanco la frustración y el buscar sin parar cómo hacer algo básico no significan que estés fracasando. Significan que finalmente estás aprendiendo. Los desarrolladores sénior no lo son porque lo sepan todo sino porque han desarrollado el músculo de encontrar soluciones a problemas que nunca han visto. La única manera de construir ese músculo es esforzarte y resolverlo tú mismo.

Si llevas tiempo usando Playwright en un gran conjunto de pruebas probablemente ya hayas probado la opción --shard para paralelizar pruebas entre varias máquinas o runners de CI. Al principio parece la solución perfecta pero, conforme crece la suite de pruebas, surge un problema frustrante: algunos shards terminan rápido y otros duran mucho más, y al final siempre esperas al más lento.

El motivo principal es que el sharding de Playwright es estático. Antes de ejecutar las pruebas se divide la lista de archivos en bloques iguales y se asigna cada bloque a una máquina o runner concreto. Por ejemplo, al shardear en cuatro runners cada uno recibe un cuarto del conjunto de pruebas. Esto funciona bien solo si todas las pruebas duran exactamente lo mismo, lo cual en la práctica nunca ocurre: hay pruebas cortas y sencillas y otras que implican flujos complejos y tardan mucho más.

La división estática provoca tres problemas claves: distribución de carga desigual donde un runner puede recibir todas las pruebas sencillas y quedarse inactivo; recursos desperdiciados porque mientras un runner está ocioso otro está saturado; y tiempos totales de ejecución más largos ya que el tiempo final lo marca el shard más lento, no el promedio.

Para ilustrarlo con un ejemplo real en GitLab CI, una suite de 53 pruebas repartida en 4 runners mostró tiempos muy dispares: runner 1 46 segundos, runner 2 1 minuto 45 segundos, runner 3 41 segundos y runner 4 1 minuto 1 segundo. El tiempo total quedó fijado por el más lento, 1 minuto 45 segundos, mientras que otro runner estuvo inactivo más de un minuto, desperdiciando recursos de CI/CD y alargando los ciclos de feedback.

La solución que proponemos es la distribución dinámica de pruebas mediante Pawdist, un distribuidor de alto rendimiento escrito en Rust que diseñé para resolver este problema. En lugar de asignar tests por adelantado, Pawdist usa una arquitectura Manager Worker: el Manager escanea todas las pruebas y crea una cola de trabajo única; los Workers se conectan al Manager y solicitan la siguiente prueba disponible; cuando un Worker termina pide la siguiente y así sucesivamente.

Esta aproximación evita que un runner se quede ocioso: un runner que acaba rápido puede tomar inmediatamente la siguiente prueba disponible y ayudar a despejar la cola, consiguiendo una utilización de recursos mucho más eficiente hasta que se completa la última prueba.

Para demostrar el impacto real creé una suite de 100 pruebas diseñada para mostrar la debilidad del sharding estático: las pruebas 1 a 50 son intencionadamente largas, entre 15 y 25 segundos cada una; las pruebas 51 a 100 son cortas, entre 1 y 15 segundos. Ejecuté la suite con 4 workers totales en tres escenarios. En un solo equipo con 4 workers la suite terminó en 6 minutos 3 segundos. Con sharding estático entre dos máquinas apareció un desequilibrio severo: el shard con las pruebas largas tardó 8 minutos 36 segundos y el otro shard 3 minutos 32 segundos, por lo que el tiempo total fue 8 minutos 36 segundos. Con Pawdist, usando distribución dinámica, la suite terminó en 6 minutos 5 segundos, casi igualando el caso ideal y eliminando la penalización del sharding estático.

Resumen de la comparativa: baseline sin sharding 6m 3s, sharding estático 8m 36s, Pawdist 6m 5s. La conclusión es clara: la distribución dinámica ofrece escalabilidad en pruebas distribuidas sin la penalización de rendimiento del sharding estático.

En Q2BSTUDIO aplicamos este tipo de soluciones avanzadas a nuestros proyectos de software a medida y aplicaciones a medida. Somos una empresa de desarrollo de software especializada en inteligencia artificial, ciberseguridad, servicios cloud y business intelligence. Si necesitas crear pipelines de pruebas eficientes como los que requiere Pawdist te ayudamos a integrarlos en arquitecturas profesionales y escalables.

Como desarrollador puedes optimizar código, pipelines y despliegues, pero hay un cuello de botella que muchas veces pasa desapercibido: la falta de sueño. La deuda de sueño es un bug silencioso en el sistema operativo de tu cerebro y, como cualquier métrica importante, se puede medir y corregir.

¿Qué es la deuda de sueño y por qué importa para los devs? Cuando no alcanzas las 7 a 9 horas recomendadas, tu cerebro no completa tareas de mantenimiento esenciales. El resultado es una caída medible en rendimiento: menor función cognitiva en la corteza prefrontal que afecta la resolución de problemas y el debugging, consolidación de memoria reducida que provoca olvidos de sintaxis o detalles de proyectos, y toma de decisiones empobrecida que aumenta la deuda técnica.

Cuantificar el problema es el primer paso. Una calculadora de deuda de sueño toma como entrada tu edad, tu objetivo de sueño y tu sueño real, y devuelve un déficit total en horas. Esta cifra convierte una sensación vaga de cansancio en un dato objetivo y accionable que puedes monitorizar, igual que hace un log de errores o una métrica de performance.

Plan de depuración personal para tu sueño: establece una rutina de apagado de servidor y apaga pantallas al menos una hora antes de acostarte para evitar la luz azul que inhibe la melatonina; automatiza horarios de sueño intentando acostarte y levantarte a la misma hora todos los días; y prioriza el sueño en la planificación del sprint, tratándolo como una tarea esencial para mantener tu rendimiento.

Evita el mito de recuperar todo el sueño el fin de semana porque eso desajusta tu ritmo circadiano. En su lugar haz commits pequeños y constantes a tu salud: siestas cortas cuando sea necesario, higiene del sueño y límites claros entre jornada laboral y descanso. Con un plan sostenido mejorarás tu capacidad para diseñar arquitecturas, depurar y tomar decisiones técnicas de mayor calidad.

Vivir como si mañana fuera a ser el último día y aprender como si fuéramos a vivir para siempre resume bien la mentalidad necesaria en tecnología: la curiosidad y la adaptación nunca caducan. Mi trayectoria como desarrollador pasó por etapas bien definidas que hoy comparto para que quien empiece o repiense su método de aprendizaje pueda identificarse y elegir con criterio.

Etapa 1 Inicial: bootcamps y escuelas presenciales. Al venir de otra profesión necesité estructura, apoyo y comunidad. Un bootcamp o programa presencial ofrece un currículo ordenado, instructores que te desbloquean y compañeros con quienes resolver noches enteras por un punto y coma perdido. Para entrar al mundo profesional un curso intensivo suele ser la forma más rápida y segura. Sin embargo, una vez que entiendes el panorama, volver a un bootcamp para temas puntuales puede resultar excesivo.

Etapa 2 Aprendizaje mediante tutoriales en vídeo. En los primeros años los cursos grabados son veloces y prácticos: sigues al instructor, replicando proyectos y aprendiendo patrones. Plataformas como Udemy son estupendas para adquirir velocidad en nuevas herramientas. Sus límites aparecen cuando la ilusión de entendimiento sustituye al esfuerzo real, cuando la sobreexplicación aburre o cuando seguir paso a paso se vuelve tedioso y no te obliga a pensar por ti mismo. Para dominar algo de verdad es imprescindible equivocarse y arreglarlo sin copiar y pegar.

Etapa 3 Documentación y proyectos personales. Ahí ocurre la transición: la documentación oficial deja de ser árida y se convierte en el mapa que necesitas. Con modelos mentales formados, leer docs y resolver errores reales te enseña más que cualquier tutorial. El aprendizaje pasa por este bucle: proyecto, problema, documentación, corrección, repetición. Esta etapa es la más cercana al trabajo real y es la que ayuda a demostrar capacidad con proyectos personales cuando las ofertas piden experiencia previa.

Etapa 4 Cursos prácticos con entregables. Con el tiempo aparecen formatos híbridos que combinan estructura y libertad: cursos con tareas reales, revisión de entregables y objetivos claros. Un ejemplo real que me ayudó a revisar y ampliar conocimientos fue el curso Full Stack Open, por su enfoque en implementar, probar y documentar soluciones completas. Para quienes buscan ritmo y responsabilidad sin perder autonomía, este tipo de cursos son ideales.

Etapa 5 Inteligencia artificial como herramienta y riesgo. La IA es un mentor disponible todo el tiempo: acelera búsquedas, genera explicaciones y propone soluciones. Pero en modo aprendizaje puede convertirse en un atajo peligroso. Pegar código generado por IA sin atravesar el ciclo de error y corrección impide construir la comprensión profunda. Mi consejo para quienes empiezan: evitar depender de agentes IA hasta dominar las bases. Para profesionales con experiencia la IA se transforma en palanca, capaz de acelerar tareas y mejorar calidad si se utiliza con criterio.

Lo que se mantiene inmutable en todas las etapas es el balance entre teoría y práctica y la necesidad de aprendizaje activo. Cambian las herramientas y los formatos, no la misión: aprender haciendo, reflexionando y iterando.

Si alguna vez has usado dispositivos ESPHome dentro de Home Assistant probablemente te hayas topado con la misma frustración que tuve yo: a veces los valores no se actualizan cuando esperas. Puede ser un sensor que informa de forma esporádica o el estado de un relé que parece desincronizado. Empecé a profundizar en la domótica y me fascinó explorar tanto el software como el hardware. Para el hardware escogí placas ESP32 con ESPHome porque son económicas, potentes y muy flexibles para proyectos DIY. Sin embargo, quería ver las actualizaciones crudas directamente desde mis dispositivos ESP sin depender solo de Home Assistant, así que construí un pequeño registrador en Python que se conecta a los dispositivos, escucha actualizaciones y guarda todo en archivos CSV diarios. Ha sido clave para depurar y mantener un historial fiable.

Por qué no usar solo los registros de Home Assistant: Home Assistant es fantástico para automatizaciones y paneles, y su integraciòn de ESPHome es excelente, pero no está pensado para ofrecer un registro bruto por dispositivo de forma absoluta. El historial interno se optimiza para las vistas y paneles de Home Assistant, poda entradas antiguas y no siempre captura cada cambio de estado. Con sensores que despiertan en deep sleep es difícil saber si el sensor no envió datos o si Home Assistant no llegó a registrar ese evento. Exportar datos a CSV desde Home Assistant puede ser engorroso si lo único que quieres es abrirlos en Excel, Pandas o Grafana. Quería una grabadora tipo caja negra que capturara cada actualización con sellos de tiempo y la guardara en CSV, y para eso la API nativa de ESPHome es perfecta.

La API nativa de ESPHome expone un puerto TCP por defecto en 6053. Es el mismo mecanismo que usa Home Assistant tras bambalinas. Con Python y la librería aioesphomeapi se puede autenticar, descubrir el dispositivo y recibir actualizaciones en streaming. Eso nos da acceso directo a sensores, switches, sensores binarios y servicios del dispositivo. En lugar de depender de lo que Home Assistant decida almacenar, obtenemos el registro primario de la fuente, incluyendo las actualizaciones esporádicas de dispositivos en deep sleep.

Conceptualmente el flujo es sencillo: conectar al dispositivo por IP, autenticar, listar entidades para mapear ids a nombres legibles, suscribirse a las actualizaciones de estado y escribir cada evento en una fila CSV con sello de tiempo ISO 8601, id de entidad, nombre amigable y valor. Para evitar archivos inmensos se rota por días, creando un CSV por fecha con cabeceras. Esta aproximación ofrece un historial por dispositivo fácil de archivar y de procesar con herramientas como Pandas o Power BI.

Detalles prácticos a tener en cuenta: manejar reconexiones automáticas cuando la red falla, ignorar valores vacíos o NaN, registrar la hora local o UTC según tu preferencia, y crear carpetas por dispositivo para tener logs ordenados por habitación o por función. Para dispositivos con deep sleep es vital que el registrador esté siempre disponible; cuando el dispositivo despierta y se conecta envía su paquete y el logger lo registra en el archivo correspondiente en ese instante.

Escalar a múltiples dispositivos es natural usando asyncio. Cada instancia del logger corre en su propia tarea, conecta a su ESPHome y escribe en su carpeta respectiva como logs/living_room, logs/bedroom o logs/kitchen. Esta estructura facilita analizar tendencias por sala, comparar sensores y detectar patrones de fallo en dispositivos concretos.

Ejemplo de estructura de archivo CSV: cada fila contiene sello de tiempo ISO 8601, id de entidad, nombre amigable y valor. Con esos CSV diarios es trivial importar datos a Pandas, combinarlos entre dispositivos y alimentar visualizaciones en Grafana o en Power BI para cuadros de mando avanzados.

Qué aprendí con el proyecto: Home Assistant es la inteligencia del hogar, pero a veces los datos crudos de dispositivo son la verdad absoluta para depurar. La API de ESPHome junto con Python y aioesphomeapi hacen que recibir datos en tiempo real sea sencillo. Y mantener logs diarios en CSV es una solución duradera y compatible con muchas herramientas de análisis.

Email sigue siendo uno de los canales de marketing más potentes pero la mayoría de los boletines son muros de texto que nadie lee. En Q2BSTUDIO combinamos desarrollo de software y creatividad para transformar esos correos en experiencias en vídeo que captan la atención y generan resultados. Somos una empresa de desarrollo de software especializada en aplicaciones a medida, software a medida, inteligencia artificial y ciberseguridad, además de ofrecer servicios cloud aws y azure y soluciones de servicios inteligencia de negocio.

Por qué los boletines rutinarios ya no funcionan: la bandeja de entrada está saturada y la fórmula clásica asunto más texto más llamada a la acción ya no destaca. La gente escanea y olvida. En cambio un mensaje en vídeo corto concentra la atención y facilita la retención del mensaje.

La evidencia lo respalda: los correos que incluyen vídeo pueden lograr hasta 300% más CTR, las personas recuerdan hasta 95% de un mensaje en vídeo frente a 10% en texto y las campañas basadas en vídeo pueden incrementar conversiones en torno al 34%. No está mal por cambiar el formato.

Casos prácticos donde los boletines en vídeo brillan: onboarding con un vídeo de bienvenida de 1 minuto, actualizaciones de producto mostrando funcionalidades en acción, historias de clientes con testimonios en vídeo que generan confianza y piezas cortas dentro de embudos de venta para explicar ventajas complejas en segundos.

HabitForge IA es una aplicación web creada para resolver un desafío central en el desarrollo personal: la brecha de motivación. Es difícil mantener nuevos hábitos porque sus efectos a largo plazo no son visibles de inmediato. HabitForge IA acorta esa distancia creando una visualización instantánea, potente y personalizada de tu yo futuro, transformando metas abstractas como mejorar la salud en imágenes concretas y emotivas que funcionan como motivador diario.

Funciones principales

Avatar privado y personalizado: los usuarios suben una foto de forma segura y la IA la transforma al instante en un avatar estilizado en distintos estilos artísticos como Cinemático, Anime o Ghibli. El resultado conserva rasgos personales clave pero protege la privacidad, ofreciendo un lienzo íntimo, atractivo y compartible.

Visualización del impacto de hábitos: se pueden seleccionar hasta tres hábitos simultáneamente, todos positivos o todos negativos. La aplicación muestra los efectos acumulados físicos, mentales y ambientales a lo largo de distintos plazos entre 21 días y 5 años. Los hábitos positivos revelan la mejora gradual, mientras que los negativos exponen el coste oculto de decisiones como dormir mal, el scroll interminable o la inactividad.

Creación de hábitos personalizados: además de la biblioteca curada, los usuarios pueden añadir hábitos personalizados. La IA analiza al instante el hábito, genera una descripción útil y crea las instrucciones visuales necesarias para adaptar la transformación del avatar en tiempo real.

Camino de recuperación: cada hábito negativo puede contrarrestarse. Con un solo clic se pueden sustituir hábitos perjudiciales por alternativas saludables y visualizar el efecto de recuperación de forma inmediata.

Coaching impulsado por IA: además de imágenes, HabitForge IA actúa como un coach de bienestar portátil. Para cada hábito ofrece beneficios clave, errores comunes y consejos accionables para ayudar a mantener la constancia.

Guardar y compartir: las transformaciones se pueden guardar en una galería personal dentro de la app, descargar como composiciones de antes y después y compartir directamente en redes para inspirar a otros.

Flujo de usuario

La experiencia está diseñada para ser intuitiva e inspiradora: página de aterrizaje con mensaje claro Visualiza tu yo futuro hoy y llamada a la acción para comenzar la transformación. Paso 1 Avatar: subir foto y elegir estilo artístico, la IA genera un avatar privacidad primero. Paso 2 Selección de hábitos y visualización: mostrar el avatar en el visualizador, elegir hasta 3 hábitos y un plazo, pulsar Mostrar mi transformación. Paso 3 Revelación: un deslizador antes y después muestra los cambios en piel, energía y entorno según los hábitos. El usuario puede ajustar plazos, leer consejos de la IA, probar intercambios en el Camino de recuperación y guardar o compartir resultados.

Tecnología y diseño multimodal

HabitForge IA aprovecha capacidades multimodales avanzadas combinando imagen y texto para producir imagen y datos estructurados. Los modelos multimodales generan avatares y transformaciones dinámicas en función de prompts que codifican manifestaciones fisiológicas, escala de intensidad y narrativa ambiental. Para análisis de texto y salida JSON se emplean esquemas estrictos que garantizan resultados estructurados y fiables para la interfaz.

Cómo se construyó con Google AI Studio

Google AI Studio fue el motor que dio vida a la aplicación. No solo generó fragmentos de código; participó en el diseño de funciones, refinamiento de UX, pruebas iterativas y la dirección artística de las visualizaciones. Actuó como socio de desarrollo, sugiriendo mejoras, probando respuestas y afinando prompts para que las transformaciones resultaran creíbles y específicas para cada usuario.

Canal multimodal principal

Pipeline de avatar privacidad primero: imagen de usuario más prompt textual hacia el modelo de generación para obtener un avatar estilizado que preserve rasgos sin almacenar la foto cruda. Pipeline de transformación dinámica: el avatar más un prompt que describe hábitos y plazo generan la imagen posterior con cambios en apariencia y ambiente. Pipeline de análisis de texto a datos: hábitos personalizados enviados con un esquema de respuesta garantizan perfiles de hábito con clasificación, resumen de impacto y prompts para el editor visual.

Sobre Q2BSTUDIO

SignalForms ya disponibles en la rama main para early adopters. SignalForms se han fusionado oficialmente en la rama main y existe una etiqueta de lanzamiento next de Angular que incluye esta novedad. Esto significa que quienes quieran experimentar pueden probarlo ya, aunque sigue en estado pre experimental. No espere que todo funcione a la perfección; las APIs pueden cambiar, se corregirán errores y la documentación se actualizará. Si desea estar en la vanguardia, adelante.

Resumen de la sesión de preguntas y respuestas con Mark y Jeremy. En la habitual sesión de Q A el tema de SignalForms surgió con frecuencia. Hubo una pregunta sobre el futuro de Reactive Forms y Jeremy comentó que a largo plazo SignalForms están pensadas para sustituir tanto Reactive como Template driven forms, aunque eso no implica que se vayan a eliminar de inmediato, por lo que no es necesario reescribir el código de formularios existente. Tiempo aproximado 5 45.

La mayor parte de la sesión trató Zoneless. Al preguntar por los cambios arquitectónicos, Jeremy explicó que ahora los desarrolladores deberán estar más conscientes de qué estado cambia. Si usa Signals, esa es la representación nativa de estado en Angular y funciona de forma natural. Si no usa Signals, sigue funcionando pero es más complicado. Tiempo aproximado 49 30.

Jeremy también dio una actualización sobre la visión más amplia para modernizar Angular incluyendo componentes sin selector, componentes Signal sin hooks de ciclo de vida, un nuevo formato de autoría y TypeScript nativo en plantillas. Siguen trabajando en esta visión sin un calendario concreto. Tiempo aproximado 1 04 20. Al final Mark anunció otra retransmisión en directo programada para el 16 de septiembre centrada en Angular y AI.

Mutaciones en la comunidad para SignalStore. Aunque Angular por ahora prioriza SignalForms, la comunidad impulsa soporte de mutaciones en librerías como ngrx toolkit. En particular se ha introducido una característica de mutation que puede usarse sin SignalStore completa. El término mutaciones se usa para describir operaciones que actualizan estado en el servidor mediante POST PUT o DELETE. La versión de ngrx toolkit maneja condiciones de carrera y expone información de estado tanto por mutación como globalmente, con metadatos similares a los de resources. Es una opción práctica para quien ya quiere adoptar Signals plenamente, aunque una solución oficial podría llegar en el futuro.

Costes ocultos de actualizar Angular. Actualizar Angular con ng update puede ser sencillo, pero el gran reto son las bibliotecas de terceros que pueden quedarse desactualizadas o sin mantenimiento. Este es el tema del último podcast Angular Space, donde se debatieron los costes ocultos de mantener dependencias y actualizar proyectos grandes.

Analog.js deja de soportar el formato ng. Analog js ha retirado el soporte para el formato ng, una sintaxis alternativa que ponía el foco en la plantilla y evitaba el uso de clases. Su introducción generó debate en la comunidad y el equipo de Angular ha mencionado que exploran internamente formatos similares que podrían salir de esos experimentos.

Resumen del verano y postmortem de Nx. El equipo de Angular publicó una recopilación de las novedades implementadas durante el verano, ideal para ponerse al día. Por su parte Nx publicó un postmortem sobre un incidente reciente en el que se publicaron paquetes maliciosos en npm mediante una explotación de GitHub Actions, explicando lo ocurrido y las medidas de seguridad reforzadas.