A pesar de la emergencia de DevOps para unir los equipos de desarrollo, soporte y SRE mediante el uso de procesos comunes, todavía enfrentamos desafíos culturales y de herramientas que crean silos entre el desarrollo y SRE. Específicamente, a menudo utilizamos diferentes herramientas para lograr pruebas similares: por ejemplo, validar la experiencia del usuario en producción utilizando Monitorización Sintética y en desarrollo utilizando pruebas de extremo a extremo. Al unir fuerzas en torno a herramientas comunes, podemos utilizar la misma herramienta tanto para la monitorización en producción como para las pruebas dentro de CI. En esta charla, discutiré cómo la Monitorización Sintética y las Pruebas de Extremo a Extremo son dos caras de la misma moneda. Además, mostraré cómo se pueden lograr la monitorización en producción y las pruebas en desarrollo para aplicaciones basadas en JavaScript utilizando Playwright con Typescript, GitHub Actions y Elastic Synthetics.
This talk has been presented at DevOps.js Conf 2024, check out the latest edition of this JavaScript Conference.
FAQ
La monitorización sintética implica ejecutar scripts en un horario regular para probar la disponibilidad de una aplicación, simulando acciones de usuarios para asegurarse de que pueden completar flujos de trabajo. Las pruebas de extremo a extremo involucran el uso de un framework de automatización para validar que una aplicación funciona como se espera siguiendo el flujo de trabajo del usuario. Ambas prácticas son similares ya que ambas automatizan operaciones de usuario y pueden utilizar herramientas comunes para optimizar los esfuerzos de desarrollo y operaciones.
En la implementación descrita, se utilizan Playwright para pruebas de extremo a extremo y Elastic Synthetics para la monitorización sintética. Además, se menciona el uso de GitHub Actions para ejecutar estas pruebas en el entorno de integración continua (CI).
El desplazamiento a la izquierda en DevOps implica integrar prácticas de prueba y monitoreo más temprano en el ciclo de desarrollo de software. Esto permite identificar y resolver problemas antes en el proceso, lo que puede mejorar la colaboración entre equipos y reducir los tiempos de resolución de errores, llevando a una mayor calidad y estabilidad del producto final.
Los desafíos incluyen la falta de empatía y entendimiento entre roles distintos como SRE, ingenieros de DevOps y desarrolladores, barreras culturales y organizativas, y el uso de diferentes conjuntos de herramientas para objetivos similares, lo que puede llevar a esfuerzos duplicados y malentendidos sobre cómo deberían funcionar los sistemas.
Playwright es una biblioteca de pruebas de extremo a extremo mantenida por Microsoft que permite automatizar el flujo de trabajo del usuario en aplicaciones web. Se utiliza para simular acciones como clics e ingreso de texto en una aplicación, verificando así que la aplicación funcione como se espera según la especificación.
Elastic Synthetics se utiliza para envolver pruebas de Playwright y ejecutarlas como monitores sintéticos en producción, lo que permite capturar actividades de monitorización y ejecutarlas según un horario. Esto ayuda a asegurar que la aplicación esté funcionando correctamente en el ambiente de producción.
GitHub Actions se utiliza para ejecutar pruebas de Playwright y monitores de Elastic Synthetics en el entorno de integración continua. Esto permite realizar pruebas y monitorización como parte de la verificación previa a la implementación, asegurando que los cambios en el código mantienen la calidad y la funcionalidad esperadas antes de ser desplegados.
La charla analiza la relación entre la monitorización sintética y las pruebas de extremo a extremo, enfatizando la importancia de utilizar un conjunto de herramientas comunes y desplazar los monitores hacia la izquierda como código. Se abordan los desafíos de la colaboración y el desplazamiento hacia la izquierda, incluyendo los silos existentes, las barreras culturales y las diferentes prioridades. Se explica el proceso de convertir una prueba de Playwright en un monitor, junto con el envoltorio de la prueba como un monitor utilizando el proyecto Synthetics. Se cubre la ejecución y implementación del monitor, enfatizando la importancia de configurar correctamente los parámetros y variables de entorno. La charla concluye con la importancia de la monitorización, la resolución de problemas y la colaboración entre roles.
Soy Carly Richmond, una Defensora Principal del Desarrollador en Elastic. Hoy, hablaré sobre la relación entre la monitorización sintética y las pruebas de extremo a extremo. Utilizar diferentes herramientas para esto es duplicar esfuerzos. Exploraremos un ejemplo de cómo utilizar Playwright, GitHub Actions y Elastic Synthetics para desplazar las monitorizaciones hacia la izquierda como código y fomentar la colaboración.
¡Hola, DevOpsJS! Es genial verlos a todos hoy. Mi nombre es Carly Richmond. Soy una Defensora Principal del Desarrollador en Elastic. Soy una ingeniera de front-end. Y también, soy un poco fanática de las pruebas. Y hoy estoy aquí para hablarles sobre la monitorización, lo cual probablemente esperaban en una conferencia de DevOps, pero también estoy aquí para hablarles sobre las pruebas, lo cual podría haber sido una sorpresa. Estoy aquí para argumentar que la monitorización sintética y las pruebas de extremo a extremo son dos caras de la misma moneda. Son constructos muy similares. Y de hecho, utilizar diferentes herramientas para esto es duplicar esfuerzos en el lado del desarrollo y las operaciones. Vamos a ver un ejemplo de cómo se puede hacer esto para aplicaciones web en JavaScript, utilizando Playwright para JavaScript y TypeScript, GitHub Actions, y también un proveedor de observabilidad que en este caso es Elastic Synthetics, para intentar desplazar nuestras monitorizaciones hacia la izquierda como código.
2. Desafíos de la Colaboración y el Desplazamiento a la Izquierda
Short description:
En mi experiencia como desarrollador, me he enfrentado a desafíos debido a la falta de colaboración entre desarrolladores, soporte y probadores. El desplazamiento a la izquierda, aunque es una gran idea en teoría, a menudo conduce a una experiencia fragmentada. Los silos existentes, las barreras culturales y las diferentes prioridades dificultan la colaboración. La calidad se convierte en un pensamiento posterior y el uso de diferentes conjuntos de herramientas para los mismos objetivos crea confusión.
desplazamiento a la izquierda como code y tratar de colaborar más juntos. Así que primero, necesito establecer el escenario de mi experiencia porque esto es algo que al comienzo de mi carrera, realmente desearía haber tenido. Habría resuelto varios problemas con los que luché. Así que mi primer trabajo como desarrollador, que fue en 2011, fue un poco raro porque trabajé en un equipo pequeño. Tuvimos que hacer de todo. Éramos desarrolladores, éramos analistas de soporte, lidiábamos con situaciones de interrupción, pruebas de aceptación de usuarios, recopilación de requisitos. Básicamente, hice de todo y llevé muchas gorras diferentes. Y luego, fue solo cuando delegamos algunas pruebas y algo de soporte donde pude trabajar con personas y aprender algunas mejores prácticas en lugar de seguir adelante como pude. Pero luego, cuando cambié de puesto, descubrí que esa experiencia previa es muy, muy rara. De hecho, la situación normal, que todavía escucho de muchos ingenieros de DevOps y SRE, es más como un juego de Rock'em Sock'em Robots cuando se trata de desarrolladores y soporte, a veces casi en desacuerdo con ideas conflictivas. Y muy a menudo hay probadores en segundo plano, a menos que hayamos terminado con la situación en la que los desarrolladores son responsables de sus propias pruebas y validaciones. Ahora, el desplazamiento a la izquierda no es algo nuevo. Y cuando escuché por primera vez sobre esto, pensé que era una gran idea. Esto llevará a tal vez un poco más de armonía en esa situación. Tal vez, ya sabes, con la aparición de prácticas comunes, podemos trabajar juntos. Yo y otros desarrolladores podemos aprender más sobre cómo construir aplicaciones más mantenibles. Sabes, tal vez todo será genial. Y en cambio, he visto algo un poco diferente suceder donde en realidad, en algunos aspectos, tenemos todas estas grandes disciplinas adicionales. Si piensas en SRE, ingenieros de DevOps, allí tenemos ingenieros rápidos, todas estas personas que pueden profundizar en temas y mostrar experiencia. Pero aún así, no necesariamente colaboramos bien juntos. Y esto todavía puede llevar a una experiencia muy fragmentada. Y hay varias razones para eso. La primera es que especialmente en organizaciones grandes, esos silos existentes aún persisten. Y de hecho, DevOps a menudo se adopta a partir de una función de gestión de producción existente, lo que significa que no se alinea realmente con los desarrolladores porque todavía tienen esas especies de mezclas culturales y barreras en su lugar. Nuestra empatía no es muy buena. No somos muy buenos tratando de entender el otro lado de eso, porque las actividades de SRE, actividades de ingenieros de ML, actividades de desarrolladores, estas cosas son sorprendentemente diferentes, hasta el punto en que incluso las prioridades que tenemos como equipos son diferentes y pueden ser difíciles de alinear juntas también. A veces, la calidad es un poco descuidada. Los desarrolladores y la idea de desplazarse a la izquierda significa que hemos tenido que aprender todo tipo de cosas locas sobre seguridad, mejores prácticas, manejo de errores, diagnóstico de monitoreo. Y en realidad, necesitamos más ayuda porque de lo contrario solo cubrimos las grietas. Pero el mayor problema, para ser honesto, es que estamos usando conjuntos de herramientas muy diferentes, lo cual a veces tiene sentido para el rol que estamos desempeñando. Pero cuando estamos usando los
3. Desafíos de Diferentes Herramientas para las Pruebas
Short description:
En mi último trabajo de ingeniería, nos enfrentamos a desafíos debido al uso de diferentes herramientas para las pruebas de extremo a extremo y el monitoreo sintético. Esto llevó a diferentes interpretaciones de cómo debería funcionar el sistema y resultó en esfuerzos duplicados. Para abordar esto, necesitamos unirnos y utilizar un conjunto común de herramientas, desplazando los monitores a la izquierda y utilizándolos como código. Hoy les mostraré un ejemplo de cómo lograr esto utilizando Playwright para JavaScript y Elastic Synthetics para la observabilidad. También discutiremos el flujo tradicional, desde el desarrollo local hasta la ejecución de monitores en el pipeline de CI y la implementación en producción. El ejemplo que cubriremos es el flujo de inicio de sesión, que incluye la entrada de texto manual y agregar elementos al carrito.
mismas diferentes herramientas para lograr los mismos objetivos, ya no tiene mucho sentido. Y en mi último trabajo de ingeniería, lo que realmente me sorprendió fue el hecho de que estábamos usando diferentes herramientas para las pruebas de extremo a extremo y el monitoreo sintético. Y no podía entender por qué. Así que antes de entrar en la idea de lo similares que son, primero establezcamos el escenario para aquellos que son nuevos en estos términos. Las pruebas de extremo a extremo se refieren a la capacidad de utilizar un framework de automatización, como Playwright, como estamos usando hoy, o tal vez Cypress, o en una vida anterior cuando estaba construyendo aplicaciones Angular, Protractor, que afortunadamente ya no está aquí, para tratar de automatizar el flujo de trabajo del usuario, esas operaciones que realizan para interactuar con sus aplicaciones web, como clics e ingreso de texto, con el fin de validar que lo que hemos construido corresponde a esa especificación y funcionará como ellos lo pretendieron. El monitoreo sintético es básicamente cuando, en un horario periódico, ejecutamos alguna forma de script para probar la disponibilidad de nuestra aplicación cada pocos minutos o unas pocas horas potencialmente. Podríamos pensar que es algo simple, como hacer ping a un punto de conexión HTTP solo para ver si todavía está activo, pero con la aparición de monitores con guiones en los últimos años, eso también puede significar realizar recorridos de usuario, automatizando los mismos pasos que realizan para asegurarse de que un usuario realmente pueda realizar ese flujo de trabajo en ese momento en el sistema. Entonces, estamos automatizando lo mismo. Estamos automatizando el flujo de trabajo del usuario, los clics, y debido a que los estamos construyendo con diferentes herramientas, mientras yo estaba construyendo en Cypress en mi último rol de desarrollador, tenía colegas que eran SRE que estaban escribiendo estos monitores en Selenium utilizando Apica como envoltorio. Y simplemente no entiendo porque eso lleva a diferentes interpretaciones sobre cómo debería funcionar el sistema porque los flujos de trabajo no siempre funcionan de la misma manera. Y también está llevando a un esfuerzo duplicado fundamentalmente. Así que creo que necesitamos cambiar esa noción. Creo que necesitamos unirnos y tratar de utilizar un conjunto común de herramientas y básicamente desplazar los monitores a la izquierda para que los usemos como código, lo que luego puede funcionar como una especificación de prueba de extremo a extremo. Y vamos a mostrar un ejemplo de cómo hacerlo hoy. Voy a usar Playwright para JavaScript, que es una biblioteca de pruebas de extremo a extremo mantenida por Microsoft. Y tengo ejemplos en TypeScript aquí también. Tenemos acciones de GitHub para que podamos ejecutar estas pruebas en CI como parte de cualquier tipo de verificación previa a la implementación o integración. Y luego necesitamos un proveedor de observabilidad porque estamos monitoreando nuestra aplicación. Y en este caso, vamos a utilizar Elastic Synthetics para envolver nuestra prueba de Playwright y permitir que capture la actividad del monitor y ejecutarlo según un horario en producción. Todos los códigos y las diapositivas que voy a mostrar hoy están disponibles en ese código QR que pueden ver en la esquina y no se preocupen. Volverá al final. Pero antes de sumergirnos en el ejemplo, vamos a tener claro cómo encajan estos elementos en términos de un flujo tradicional.
Tomemos el ejemplo de los desarrolladores que trabajan en una nueva función. Lo que harán es construir la función junto con la escritura de un archivo de recorrido, un monitor que pueden usar como una prueba de extremo a extremo utilizando Playwright. Y ejecutarán eso como parte de su práctica de desarrollo local con suerte participando en el desarrollo impulsado por pruebas. Luego, enviarán sus cambios, el monitor y los cambios de código al control de origen y pasarán por cualquier revisión y verificaciones ejecutando estos monitores como una prueba de extremo a extremo dentro del pipeline de CI. Luego, cuando llegamos a implementar nuestra aplicación para mantener nuestros monitores sincronizados con la aplicación de producción, necesitamos poder enviarlos a donde deben ejecutarse utilizando la autenticación de clave de API, que luego se ejecutará en su propia ubicación o dentro de la ubicación proporcionada por el proveedor de observabilidad. Y luego, en este caso, persistir los resultados en Elasticsearch y luego poder ver los resultados en un panel brillante. El ejemplo que voy a cubrir hoy es el flujo de inicio de sesión que están viendo parpadear frente a ustedes en este momento. Un simple ingreso de texto manual para ingresar nombre de usuario y contraseña para ir a una pantalla de pedido y luego
4. Conversión de Prueba de Playwright en Monitor
Short description:
Para convertir la prueba de Playwright en un monitor, comenzamos verificando el formulario de inicio de sesión y obteniendo el botón. Agregamos las credenciales a los cuadros de texto de entrada y verificamos sus valores. Luego verificamos que el botón de envío esté habilitado y nos aseguramos de navegar a la página esperada.
comenzamos a agregar elementos al carrito. Entonces, primero, necesitamos esa prueba de Playwright que luego podemos convertir más tarde en un monitor. Aquí verán que tengo una prueba muy básica frente a mí aquí que básicamente está pasando por comenzar desde la línea cuatro. Vamos a la página de inicio de sesión. Estamos obteniendo el formulario de inicio de sesión utilizando el atributo de ID de prueba data como parte de este selector. Esto es lo que recomendaría como práctica porque lo último que quieres hacer, lo cual he hecho en el pasado, es acoplar esto a clases CSS que también estás usando para estilizar o a estructuras CSS complejas con padres anidados, lo que significa que tan pronto como muevas algo o cambies algo en la vista, romperás todas tus pruebas. Así que trata de evitar hacer eso. Verificamos que el formulario de inicio de sesión esté definido, luego vamos y obtenemos el botón, verificamos que esté deshabilitado, agregamos nuestras credenciales. Esta es solo una prueba que tengo. Si quieres reutilizar tus credenciales, Playwright tiene la opción de hacerlo persistiendo sus credenciales en un archivo JSON. Consulta la documentación de autenticación para eso. Pero las estamos agregando a los cuadros de texto de entrada para el nombre de usuario, verificando que el valor del cuadro de texto sea realmente lo que agregamos. Lo mismo para la contraseña. Luego verificamos que ahora podemos enviar el botón, y luego nos aseguramos de que estemos navegando a la página como esperamos.
5. Envolver Prueba como Monitor
Short description:
Para envolver la prueba como un monitor, crea un nuevo proyecto de Synthetics. Utiliza el asistente de inicio para generar un proyecto de muestra con código esqueleto. El proyecto incluye monitores de ejemplo en la carpeta de recorridos. La configuración del proyecto especifica parámetros, como la URL y las variables de entorno. También se configuran las opciones de Playwright y los ajustes del monitor. Transforma la prueba en un recorrido dividiéndola en pasos más pequeños utilizando las construcciones de recorrido y paso.
Lo que debemos hacer a continuación es envolver esto como un monitor. Y la forma de hacerlo es crear un nuevo proyecto de Synthetics. Así que tendremos una instalación global, que puedes ver aquí arriba, luego utiliza el asistente de inicio como parte del tercer comando para generar ese proyecto de muestra, que generará el código esqueleto. Así que verás, tienes la carpeta de recorridos. Estos son monitores de ejemplo que vamos a ejecutar como pruebas para mostrarte cómo empezar. Luego tienes monitores de latido ligero. Así que si quieres hacer cosas como pings, puedes mantenerlos todos en el mismo repositorio que el code, no vamos a cubrir eso hoy. Y luego tienes la configuración del proyecto con todas tus configuraciones. Si pasamos a eso, verás aquí, este es el archivo de configuración. Estoy especificando parámetros. Así que tengo la URL, puedes ver que es local host. Esto es lo que haría ping en un escenario predeterminado. Pero si nos desplazamos hasta la línea 30, verás que en realidad cuando el entorno es producción, cambio la URL para que coincida. Y eso significa que no tenemos la situación en la que el monitor fallará cuando lo enviemos porque está intentando acceder a una aplicación que se ejecuta localmente y no existe. También estoy pasando el nombre de usuario y la contraseña para poder utilizar los mismos valores recogidos del entorno en el monitor, así como en NCI y en el desarrollo local. Así que usarías un archivo de entorno localmente para gestionarlo. Luego tienes tus opciones de Playwright, según la documentación de Playwright, cualquier configuración específica que necesites. Y luego la configuración del monitor para todos los monitores del proyecto, a menos que se indique lo contrario. Así que estamos estableciendo el horario en 10 minutos. Lo tenemos ejecutando en una ubicación del Reino Unido, y luego no he configurado ninguna ubicación yo mismo. Esta es una ubicación elástica en el Reino Unido. Así que eso está bien. Si configuras una ubicación privada, se mostrará aquí. Y luego tengo la configuración del proyecto. Así que necesito saber dónde está mi implementación. Estos son los detalles de implementación en la cloud. Esto es un punto hacia una versión local en ejecución, si es eso lo que tenías, el espacio de cabana y luego el ID.
Ahora debemos transformar esa prueba que teníamos antes en un recorrido, lo que significa que queremos intentar dividirla en pasos más pequeños, lo que nos permite obtener información más detallada sobre lo que está fallando. Lo primero que notarás, si miras en la parte superior, es
6. Running and Deploying the Monitor
Short description:
Pasa el objeto de página, los parámetros y la configuración al recorrido. Anula la configuración del monitor si es necesario. Configura acciones antes y después. Divide los pasos en pasos de la página de inicio de sesión y pasos de inicio de sesión manual. Ejecuta el conjunto localmente y envía los cambios al canal de integración continua. Utiliza el entorno de nodo como desarrollo y especifica el nombre de usuario y la contraseña. Especifica un archivo JUnit para la salida del informe. Ejecuta Elastic Synthetics en la carpeta de recorridos. Envía el monitor como un monitor de producción. Especifica el entorno de nodo como producción y la clave de API. Utiliza las medidas de seguridad adecuadas. Asegúrate de que los parámetros y las variables de entorno estén configurados correctamente. Utiliza una cuenta de prueba con acciones limitadas. Evita cambios de estado irreversibles.
que nuestras importaciones son diferentes ahora. Así que tenemos un recorrido y una construcción de paso aquí. También verás para el recorrido que en realidad estoy pasando el objeto de página. Este es el objeto de Playwright, y también estoy pasando los parámetros y la configuración. Puedo anular el monitor con la configuración predeterminada, así que si quiero que se ejecute en un horario diferente, con menos frecuencia o más frecuencia, puedo hacerlo. Puedo configurar y desmontar cosas con antes y después, similar a las pruebas unitarias. Y luego tengo dos pasos. Tengo los pasos de la página de inicio de sesión, que son exactamente los mismos que los que cubrimos en el ejemplo de Playwright antes. Y luego también tengo los pasos de inicio de sesión manual, que también se han dividido. Y luego cuando ejecuto esto localmente como desarrollador, todo está en verde. Luego sé que puedo enviar mis cambios. Así que eso significa que cuando se trata del canal de integración continua, hay dos cosas que quiero que haga. Quiero poder ejecutar este conjunto y quiero poder enviar los monitores a producción junto con la implementación. Así que aquí, especificando el entorno de nodo como desarrollo, básicamente para recoger la configuración correcta, y agregando el nombre de usuario y la contraseña para que se recojan esos parámetros, voy a ejecutar el conjunto exactamente de la misma manera que antes con el mismo comando. Así que lo que también haré es especificar un archivo JUnit para la salida del informe, que obviamente no necesité hacer para el desarrollo local. Así que bajando a la línea 18, estoy, ya sabes, ordenando mis instalaciones, estoy iniciando la aplicación en ejecución localmente. Y luego lo que estoy haciendo aquí es ejecutar Elastic Synthetics dentro de la carpeta de recorridos en sí, para que pueda recoger las definiciones, por eso he especificado el directorio de trabajo. Y luego la opción de salida del informe del reportero JUnit significa que mi tarea de publicación de resultados de pruebas unitarias puede recoger esa definición y mostrarme mis resultados de prueba. Pero también necesito enviar el monitor, así que cuando implemento mi aplicación, que ocurre en segundo plano con Netlify cuando este flujo se completa, quiero poder enviar esas definiciones para ejecutarlas como un monitor de producción. Y la forma de hacerlo es especificar el entorno de nodo como producción, especificar la clave de API. Esto debe ser un secreto. No quieres publicar tus claves en tus flujos de trabajo de GitHub visibles públicamente, así que asegúrate de usar un almacén adecuado. Asegurándote de que dependa de las pruebas y no se envíe en caso de que se produzca una ejecución de prueba fallida. Nuevamente, esta vez ejecutando dentro de la carpeta principal de pruebas en lugar de la carpeta de recorridos. Y luego las tareas son que nuevamente ejecutamos las instalaciones y luego ejecutamos el envío, y esto se genera cuando ejecutas el asistente de generación. Y cuando hacemos eso, luego entramos en Elastic. Vemos que tenemos monitores, pero decimos, oh, están fallando. ¿Qué está pasando allí? Necesita poder recoger los parámetros. A menos que los especifiques en la configuración de parámetros globales, no podrá recoger las variables de entorno. Así que debes tener cuidado con eso. También es un buen momento para mencionar que si estás agregando credenciales para estas pruebas, debes asegurarte de que esta sea una cuenta de prueba que se ejecute en producción y esté limitada a realizar acciones específicas. Idealmente,
7. Monitoring, Issue Resolution, and Collaboration
Short description:
Asegúrese de configurar correctamente los roles para evitar acciones no autorizadas. Monitoree el rendimiento y las fallas. Utilice las mismas definiciones para la comunicación y resolución de problemas. Colabore entre roles y priorice la construcción de aplicaciones amigables para el usuario. Utilice herramientas comunes para flujos de trabajo unificados. No dude en hacer preguntas y acceder a recursos de código. Manténgase conectado a través de varias plataformas.
No queremos que cambie el estado de una manera irreversible. No queremos que pueda hacer cosas como realizar pagos. Por lo tanto, asegúrese de que los roles estén configurados correctamente en su aplicación para asegurarse de que alguien no pueda realizar toneladas de transacciones con una tarjeta legítima en lugar de una tarjeta de prueba o hacer cualquier cosa que no deba hacer. Porque al final del día, si estas credenciales se filtran, debes asumir un escenario catastrófico. También puedes ver cuánto tiempo están tardando, cuántas fallas han tenido en el período de tiempo, y luego podemos comenzar a hacer cosas inteligentes. Podemos ver cuándo falla. Podemos ver en qué paso está fallando. Podemos ver cuál es la traza. Podemos ver cosas como cuánto tiempo tardan los pasos, lo cual es útil para mí porque solía tener una situación en la que mi prueba de intención se volvía cada vez más larga. Entonces, la idea de un monitor es poder ver si está comenzando a ejecutarse un poco más lento y luego puedes averiguar si tal vez están comenzando a degradarse, tal vez haya optimizaciones que puedas hacer para que sea una experiencia más eficiente para el usuario. Eso es todo súper útil. Muchas veces puedes hacer cosas inteligentes como alertas. Ahora, la esperanza es que esto atrape algo antes de que lo haga el usuario, pero eso no siempre va a suceder. A veces, un usuario encontrará un problema y lo que podemos hacer es utilizar estas mismas definiciones como comunicación para lo que está experimentando un usuario. Entonces, si escribimos una especificación o grabamos una especificación, luego podemos usar eso para recrear el problema, trabajar en la solución y luego retroceder desde ese flujo inicial que cubrimos antes. Porque en esta situación particular, DevOps para mí, dada mi experiencia, dadas los desafíos de los que hablé al principio, se trata de unirnos, asegurarnos de colaborar, independientemente de si somos SRE, ingenieros de DevOps, desarrolladores, independientemente de los desafíos y las prioridades que tengamos, todos tenemos un objetivo y es asegurarnos básicamente de que estamos construyendo aplicaciones increíbles que los usuarios están felices de usar. Así que es hora de unirnos y si las herramientas comunes pueden ayudarnos a hacer eso, en este caso con las pruebas de extremo a extremo y los monitores sintéticos siendo dos caras de la misma moneda, hagámoslo. Así que la próxima vez que estés revisando tu suite de extremo a extremo o tus monitores scriptados, solo asómate por encima de esa barrera y pregúntate si están escribiendo lo mismo. ¿Los flujos de trabajo están sincronizados? ¿Y realmente hay una forma en la que podamos escribir las mismas definiciones utilizando herramientas comunes? Así que muchas gracias, DevOpsJS, ha sido un placer absoluto. Estaré por aquí, así que no dudes en hacerme cualquier pregunta sobre Playwright, sobre monitoreo sintético, estaré aquí para eso. También puedes sumergirte en el código, que puedes consultar en el código QR que se muestra allí, y también hay una copia de las diapositivas allí. Si no me encuentras por aquí y se te ocurre algo después, estoy en X, estoy en LinkedIn, estoy en Masterdod, solo contáctame y saluda, nos vemos la próxima vez. ¡Adiós!
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
This Talk focuses on effective React state management and lessons learned over the past 10 years. Key points include separating related state, utilizing UseReducer for protecting state and updating multiple pieces of state simultaneously, avoiding unnecessary state syncing with useEffect, using abstractions like React Query or SWR for fetching data, simplifying state management with custom hooks, and leveraging refs and third-party libraries for managing state. Additional resources and services are also provided for further learning and support.
React and TypeScript have a strong relationship, with TypeScript offering benefits like better type checking and contract enforcement. Failing early and failing hard is important in software development to catch errors and debug effectively. TypeScript provides early detection of errors and ensures data accuracy in components and hooks. It offers superior type safety but can become complex as the codebase grows. Using union types in props can resolve errors and address dependencies. Dynamic communication and type contracts can be achieved through generics. Understanding React's built-in types and hooks like useState and useRef is crucial for leveraging their functionality.
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía). En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también. Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso. (Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.
¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.
¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()? En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor. Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Durante esta masterclass, los participantes revisarán los patrones esenciales de JavaScript que todo desarrollador debería conocer. A través de ejercicios prácticos, ejemplos del mundo real y discusiones interactivas, los asistentes profundizarán su comprensión de las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables. Al final de la masterclass, los participantes ganarán una nueva confianza en su capacidad para escribir código JavaScript de alta calidad que resista el paso del tiempo. Puntos Cubiertos: 1. Introducción a los Patrones de JavaScript2. Patrones Fundamentales3. Patrones de Creación de Objetos4. Patrones de Comportamiento5. Patrones Arquitectónicos6. Ejercicios Prácticos y Estudios de Caso Cómo Ayudará a los Desarrolladores: - Obtener una comprensión profunda de los patrones de JavaScript y sus aplicaciones en escenarios del mundo real- Aprender las mejores prácticas para organizar el código, resolver desafíos comunes y diseñar arquitecturas escalables- Mejorar las habilidades de resolución de problemas y la legibilidad del código- Mejorar la colaboración y la comunicación dentro de los equipos de desarrollo- Acelerar el crecimiento de la carrera y las oportunidades de avance en la industria del software
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles. Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador. Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E. Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes. Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Comments