¿Por qué es tan lento el CI?

Rate this content
Bookmark

Todos nos hemos preguntado esto mientras esperamos una eternidad a que termine nuestro trabajo de CI. Un CI lento no solo arruina la productividad del desarrollador, rompiendo nuestra concentración, sino que también cuesta dinero en tarifas de computación en la nube y desperdicia enormes cantidades de electricidad. Vamos a adentrarnos en por qué ocurre esto y cómo podemos solucionarlo con herramientas mejores y más rápidas.

27 min
24 Mar, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Un CI lento tiene un impacto negativo en la productividad y las finanzas. La depuración de flujos de trabajo de CI y la lentitud de las herramientas es aún peor. Las dependencias afectan al CI y esperar por NPM o YARN es frustrante. El trabajo ideal de CI involucra programas nativos para trabajos estáticos y entornos livianos para trabajos dinámicos. Mejorar el rendimiento del formateador y el linting es una prioridad. La optimización del rendimiento y las herramientas rápidas son esenciales para el CI y los desarrolladores que utilizan hardware más lento.

Available in English

1. El impacto de un CI lento en la productividad del desarrollador

Short description:

Hola a todos. Mi nombre es Nicholas. Me gustaría hablarles sobre por qué su CI es tan malditamente genial. Esperar por el CI tiene un efecto directo y negativo en la productividad y las finanzas. Cuando nos encontramos con una sincronización de tiempo como un CI lento, holgazanear o comenzar otra tarea no son soluciones efectivas. Cambiar de tarea en proyectos de desarrollo de software conduce a una menor finalización de tareas y interrumpe el flujo. Un CI lento interrumpe el flujo de trabajo y disminuye la eficacia y la eficiencia. Olvidarse de un trabajo de CI puede causar retrasos significativos en la fusión de PR.

Hola a todos. Mi nombre es Nicholas. Soy un desarrollador de software en Rome Tools y me gustaría hablarles a todos sobre por qué su CI es tan malditamente genial. Todos hemos estado ahí. Has subido tu último código a GitHub, tu servicio de CI está funcionando y está tardando una eternidad. Esperas y esperas y esperas, solo para obtener el resultado 5, 10, incluso 20 minutos más tarde. Es molesto, es disruptivo, es una pérdida de tu maldito tiempo. Normalmente, simplemente aceptamos esto como una verdad eterna. El CI es genial. No creo que eso esté bien. Tener que esperar por el CI tiene un efecto directo y negativo, tanto en tu productividad como en tus finanzas. Comencemos con un recurso que nos importa a todos. El tiempo del desarrollador. No sé ustedes, pero cuando me encuentro con una sincronización de tiempo como un CI lento, hago una de dos cosas. Me relajo o comienzo otra tarea. Holgazanear claramente es negativo. Claro, todos merecemos descansos, pero no cada vez que subimos código. Nuestro CI no debería determinar cuándo trabajamos o no. Pero Nick, podrías simplemente comenzar otra tarea. Y sí, comenzar otra tarea parece tentador. Todos somos capaces de hacer varias tareas a la vez. Resulta que no, no lo somos. En el artículo, Interrupción de tareas en proyectos de desarrollo de software, los autores midieron el efecto del cambio de tarea en la productividad. No fue bueno. En particular, señalaron que las auto-interrupciones, básicamente cuando cambias de tarea a propósito, tienden a ser más disruptivas que las interrupciones externas y conducen a una menor finalización de tareas. Con un CI lento, este flujo se interrumpe constantemente. Terminas cambiando entre los trabajos de CI y tu nueva tarea, perdiendo tu contexto de trabajo y, por lo tanto, tu eficacia y eficiencia. O peor aún, te enfocas en tu nueva tarea, te olvidas de tu trabajo de CI y solo recuerdas unas horas después de que tu trabajo está hecho. Le envías un mensaje a tu revisor solo para darte cuenta de que se ha ido a casa. De repente, un PR rápido tarda dos días o más en fusionarse.

2. Depuración de flujos de trabajo de CI y lentitud de herramientas

Short description:

Aún peor es cuando tienes que depurar un flujo de trabajo de CI. Un ciclo de desarrollo de 15 minutos no es aceptable. Un CI lento significa más tiempo de cálculo, lo que significa más dinero. Vamos a averiguar por qué el CI es lento. Hay dos tipos de trabajos de CI, trabajos estáticos y trabajos dinámicos. Si tu trabajo de CI es lento, es probable que tus herramientas sean lentas. Estas herramientas también son lentas en su tiempo de instalación. Las dependencias son una parte necesaria del desarrollo de software moderno.

Aún peor es cuando tienes que depurar un flujo de trabajo de CI. Cada vez que tengo que depurar uno, es tan horrible. Terminé ajustando una configuración, esperando a que el trabajo se complete, distrayéndome, y solo viendo los resultados 15 minutos después. Un ciclo de desarrollo de 15 minutos no es aceptable en esta época. Pero no solo se trata del tiempo del desarrollador. Un CI lento significa más tiempo de cálculo, lo que, como cualquiera que haya mirado con asombro su factura de AWS sabe, significa más dinero. Un ejemplo de esto es la instancia gratuita de GitLab en el escritorio, que alberga una serie de proyectos de software gratuitos, como Mesa, los controladores del kernel de Linux y muchos otros. Experimentaron un período masivo de crecimiento a finales de 2019 y principios de 2020. Sin embargo, sus gastos aumentaron en consecuencia, primero a $75,000 en 2019. Y luego se proyectaba que alcanzarían los $90,000 en 2020. Lograron reducir los costos antes de quedarse sin dinero, pero aún así, para un proyecto de código abierto, eso es una cantidad enorme para gastar en CI. Hagámoslo mejor. Vamos a averiguar por qué el CI es lento. Para hacerlo, debemos analizar qué hace un trabajo de CI. En su núcleo, hay dos tipos de trabajos de CI, trabajos estáticos y trabajos dinámicos. Los trabajos estáticos aplican herramientas de desarrollo, como un Linter, Bundler, Formateador, etc., a tu código sin ejecutarlo. Los trabajos dinámicos también pueden aplicar herramientas, pero deben ejecutar tu código. Nos vamos a centrar en los trabajos estáticos pero muchas de estas lecciones también se aplican a los trabajos dinámicos. En cualquier caso, si tu trabajo de CI es lento, es probable que tus herramientas sean lentas. Pero ¿qué quiero decir exactamente con lento? Por supuesto, me refiero a que las herramientas son lentas en su tiempo de ejecución. Sin embargo, para el CI, hay un segundo tipo de lentitud. Estas herramientas también son lentas en su tiempo de instalación. Tomemos ESLint. Es una gran herramienta. Sin embargo, al igual que muchas herramientas en el ecosistema de JavaScript, tiene muchas dependencias. Esto no es una charla para avergonzar a las dependencias. Yo uso dependencias. Tú usas dependencias.

3. Impacto de las Dependencias en CI

Short description:

Las dependencias impactan en CI. Esperar por NPM o YARN es frustrante. Node es un tiempo de ejecución masivo. La mayoría de las herramientas están escritas en JavaScript, lo cual no es ideal para las herramientas de desarrollo. Usamos Rust, Go y Zig para obtener un mejor rendimiento. Rust se compila en un binario estático, eliminando la necesidad de dependencias. Las herramientas de JavaScript implican un trabajo redundante debido al ecosistema fragmentado y la necesidad de analizar árboles de sintaxis.

Son una parte necesaria del desarrollo de software moderno. Pero las dependencias sí tienen un impacto en tu CI. Específicamente, tienes que instalarlas. Y a nadie le gusta esperar a que NPM o YARN hagan su trabajo. Y con JavaScript, siempre está la dependencia más grande de todas. Node. Tienes que descargar este tiempo de ejecución masivo solo para ejecutar tus otras dependencias. ¿Cuántas veces un servicio de CI tiene que iniciar un contenedor de Docker con Node solo para ejecutar una herramienta como ESLint o webpack? Y volviendo al tiempo de ejecución. ¿Por qué estas herramientas son lentas? En Rome, hemos pensado mucho en esta pregunta. Primero y más obviamente, es porque la mayoría de las herramientas están escritas en JavaScript, y JavaScript no es el lenguaje ideal para las herramientas de desarrollo. Utiliza mucha memoria, es difícil escribir código concurrente seguro y requiere un tiempo de ejecución. La solución es, bueno, no escribir las herramientas en JavaScript. Usamos Rust. ESbuild utiliza Go. Bun utiliza Zig. En nuestro caso, descubrimos que Rust nos ha dado beneficios significativos. Primero escribimos Rome en TypeScript. Tuvimos que exprimir el rendimiento con un JavaScript cuidadosamente optimizado y nuestras propias primitivas de bajo nivel. En Rust, obtuvimos un muy buen rendimiento desde el principio. Segundo, debido a que Rust se compila en un binario estático, ya no tenemos que instalar dependencias ni un proceso de CI. Simplemente podemos descargar un binario. Y finalmente, hay un aspecto del tooling de JavaScript que creemos que se subestima. Y ese es el problema del trabajo redundante. El ecosistema de tooling de JavaScript está extremadamente fragmentado. Usamos diferentes herramientas para lintear, formatear, empaquetar, etc. Cada herramienta, por lo tanto, necesita analizar y representar el JavaScript como un árbol de sintaxis. Si recuerdas tus compiladores, recordarás que los árboles de sintaxis ocupan una cantidad significativa de memoria. ¿Alguna vez te has preguntado por qué IntelliJ es lento? Almacena todos estos árboles de sintaxis. Sin mencionar que el análisis implica E/S, lo cual siempre conlleva su propia sobrecarga. Por lo tanto, cada herramienta necesita

4. El Trabajo Ideal de CI y Mejorando el Formateo

Short description:

Usa tres herramientas, tres veces el tiempo de análisis y tres veces la memoria. Nuestro trabajo ideal de CI se parece a programas nativos para trabajos estáticos y entornos más livianos para trabajos dinámicos. Roam tiene como objetivo ser la solución integral para todo JavaScript. El linting, especialmente la regla de prettier, puede ser lento y obstaculizar el flujo de desarrollo. Estamos trabajando para mejorar el formateo.

haga su trabajo. Usa tres herramientas, tres veces el tiempo de análisis y tres veces la memoria. Con Roam, se encarga del linting, formateo, empaquetado, y más. Eso significa una etapa de análisis y un árbol de sintaxis. No hay cálculos ni memoria desperdiciados.

Con todo esto en mente, ¿cómo se ve nuestro trabajo ideal de CI? En el caso de trabajos estáticos, estos trabajos deberían funcionar como programas nativos sin JavaScript runtime involucrado. No hay realmente ninguna razón para ejecutar Node o Docker para un linter o bundler. Se pueden usar como una línea de comandos o como una API. En ese caso, la expectativa de performance debería ser igual a cualquier otra API REST. Lo llamas, obtienes un resultado en menos de un segundo. Por supuesto, para trabajos dinámicos, donde necesitamos ejecutar el código, aún podemos iniciar un runtime. Pero tal vez podamos optar por entornos más livianos. Algo como un AWS Lambda o un CloudFlare worker podría ser suficiente.

Entonces, ¿dónde encaja Roam en esto? Por ahora, nos enfocamos en ofrecer herramientas rápidas y nativas de JavaScript. Nuestro plan a largo plazo es ser la solución integral para todo JavaScript. Esperamos que en el futuro, estas herramientas sean el reemplazo para trabajos estáticos de CI. Pero, ¿por dónde empezamos? Por supuesto, no podríamos abordar todas las herramientas simultáneamente. Decidimos investigar, mirar repositorios de código abierto y ver qué era lento en su configuración de herramientas. Descubrimos que el linting generalmente era bastante lento. Pero en particular, una regla se destacaba: prettier. Si no estás familiarizado, hay una regla de ES lint que verifica si tu código está formateado correctamente ejecutando prettier en tu código y viendo si hay algún cambio. En el caso de Babel, un compilador de JavaScript originalmente escrito por el fundador de Roam, Sebastian, la regla de ES lint de prettier tarda más de seis segundos en completarse. Con Webpack, esta regla tarda cinco segundos. Puedes estar diciendo en este punto, ¿seis segundos? Eso no es mucho. Y estaría de acuerdo en abstracto. Pero en realidad, seis segundos marcan la diferencia entre ejecutar tu linter como un observador local y ejecutarlo en CI. Si tarda seis segundos en obtener los resultados del linter, es probable que no integres el linter en tu flujo de desarrollo. Probablemente no quieras llamarlo a través de una API REST. En cambio, confiarás en ejecutarlo como una tarea de CI. Esperarás más tiempo antes de ver posibles problemas en tu código.

5. Mejorando el Rendimiento del Formateador y Winting

Short description:

Me encanta prettier, pero puede volverse lento en archivos grandes. Queríamos un formateador con el mismo rendimiento que el formateador de Rust pero para JavaScript. Nuestro formateador es tolerante a errores y se lanzará el 28 de marzo. Funciona significativamente más rápido que prettier en varios frameworks y archivos grandes. Nuestro próximo objetivo es mejorar la velocidad del winting y aprovechar el análisis basado en CST para una mejor preservación del código.

No me malinterpretes. Me encanta prettier, pero puede volverse notablemente lento en archivos grandes. En particular, nos inspiramos en el formateador de Rust, que es súper rápido. Decidimos que queríamos un formateador del mismo nivel de rendimiento, pero para JavaScript. También queríamos un formateador que estuviera integrado en tu entorno de desarrollo.

Una característica particular de las herramientas para desarrolladores que nos encanta se llama tolerancia a errores. Una herramienta es tolerante a errores si funciona incluso cuando tu código tiene errores, ya sean sintácticos o semánticos. Trabajamos mucho para hacer que el formateador sea tolerante a errores. De esa manera, puede hacer que tu código se vea bien sin importar qué.

Estamos súper emocionados de anunciar que nuestro formateador se lanzará el 28 de marzo. Nos encantaría mostrar un adelanto del rendimiento de nuestro formateador. Primero, tenemos Dojo, un framework front-end. Ejecutando el formateador en una biblioteca empaquetada, prettier tarda 75 milisegundos, lo cual no está mal, pero roam está en solo 10 milisegundos. Para Svelte, prettier tarda hasta 750 milisegundos, casi un segundo, mientras que roam está en solo 200 milisegundos. Y finalmente, está el gigante que es el archivo checker.ts de TypeScript, con más de 44,000 líneas, o 2.64 megabytes. No sé si alguna vez has abierto este archivo en un editor, pero te diré ahora, ralentiza mi editor hasta hacerlo casi inusable. Prettier tarda más de dos segundos en formatear este archivo. Nosotros lo hacemos en 335 milisegundos.

Pero eso es solo el comienzo. Nuestro próximo objetivo es el winting. Como mencioné antes, el winting es bastante lento en JavaScript. ESLint puede tardar fácilmente 15, 30 segundos en ejecutarse en una computadora potente. Queremos ser una décima parte de eso. El winting también aprovechará el poder de nuestro Árbol de Sintaxis Concreta o análisis basado en CST. Una vez más, si estás familiarizado con los compiladores, sabrás que los analizadores generalmente producen lo que se llama un Árbol de Sintaxis Abstracta o AST. Los AST son geniales porque abstraen detalles innecesarios, como espacios en blanco o comentarios. Sin embargo, resulta que estos detalles supuestamente innecesarios son bastante importantes para otras herramientas para desarrolladores. Específicamente, es realmente difícil hacer algo como analizar el código en un AST, modificar el AST y luego convertirlo nuevamente en código sin reorganizar por completo el código, creando así una gran diferencia en git. Con un CST, todo se preserva. Comentarios, espacios en blanco, todo.

QnA

CST-based Linting and Q&A

Short description:

Eso significa que convertir un CST de vuelta a código con solo una diferencia mínima es extremadamente fácil, lo que a su vez abre un conjunto completo de potentes funciones de modificación de código. Para resumir, CI es lento porque nuestras herramientas son lentas, tanto en el tiempo de instalación como en el tiempo de ejecución. Necesitamos herramientas nativas rápidas para JavaScript. Sí, una charla realmente genial y Nicholas, gracias por compartir eso con nosotros. Echemos un vistazo a nuestros resultados de Slido. ¿Cuál es la herramienta más lenta y molesta? Comencemos con algunas preguntas y respuestas. Muy bien, genial. Entonces, comencemos con ¿qué pasa con las pruebas? ¿No hay problemas inherentes de rendimiento con las pruebas? Sí. Estoy de acuerdo con eso. Las pruebas son, sin duda, lo que hace que CI sea más lento, y hay posibles soluciones en esta área.

Eso significa que convertir un CST de vuelta a código con solo una diferencia mínima es extremadamente fácil, lo que a su vez abre un conjunto completo de potentes funciones de modificación de código. Estamos muy emocionados de demostrar las posibilidades del linting basado en CST. Nuestro linter estará disponible a finales del segundo trimestre y estamos muy emocionados de demostrar las posibilidades del linting basado en CST entre diferentes lenguajes.

Para resumir, CI es lento porque nuestras herramientas son lentas, tanto en el tiempo de instalación como en el tiempo de ejecución. Son lentas porque utilizan lenguajes más lentos que dependen de tiempos de ejecución y containers. Para hacer que CI sea más rápido, necesitamos herramientas nativas rápidas para JavaScript.

Si estos objetivos te parecen interesantes, pronto estaremos contratando. No dudes en ponerte en contacto con Nicholas en RoamTools.com o a través de Twitter. Gracias.

Sí, una charla realmente genial y Nicholas, gracias por compartir eso con nosotros. En realidad, fue una charla bastante rápida sobre lo lento que es CI, ¿verdad? Sí, no quería hacerte perder el tiempo. Pero fue buena. Pero has desempaquetado mucho ahí, así que buena charla. Echemos un vistazo a nuestros resultados de Slido. Estoy muy intrigado por saber qué piensa la gente. ¿Cuál es la herramienta más lenta y molesta? Vamos a verlo juntos. Entonces, Bundler, el 50% dice Bundler. Vale, eso es interesante. Pero en segundo lugar, tenemos el IDE. Así que si quieres compartir en el chat qué IDE estás usando, nos encantaría saber cuáles estás usando y cuáles encuentras bastante lentos. Y a menos que eso sea como etcd allí, me encantaría desempaquetar también el etal o et cetera para saber qué está en tercer lugar. Qué está en tercer lugar, así que cuéntanos qué otras herramientas crees que no están en la lista. Nos encantaría saber sobre ellas. Y sí, escuchemos qué preguntas tenía la gente, Nicholas. Comencemos con algunas de las preguntas y respuestas.

Muy bien, genial. Entonces, comencemos con ¿qué pasa con las pruebas? ¿No hay problemas inherentes de rendimiento con las pruebas? Sí. Estoy de acuerdo con eso. Diría que las pruebas son, sin duda, lo que hace que CI sea más lento, y hay un límite inherente en las pruebas que son simplemente código que debes ejecutar. Pero creo que hay posibles soluciones en esta área.

Optimización de Tiempo de Ejecución y Pruebas en CI

Short description:

Puedes optimizar la sobrecarga de tiempo de ejecución, explorar posibles optimizaciones de JavaScript y precompilar el JavaScript. Las pruebas y el benchmarking son tareas pesadas en el proceso, pero hay técnicas que se pueden tomar de grandes empresas. Por ejemplo, ejecutar benchmarks y pruebas relevantes en lugar de la suite completa. Un código más limpio tanto en las herramientas como en el código normal puede ayudar a evitar la lentitud de CI. El rendimiento ha sido descuidado en el mundo de las herramientas.

Por ejemplo, puedes reducir considerablemente la sobrecarga de tiempo de ejecución. Puedes utilizar algo como una curva de trabajo optimizada para tener una rápida aceleración y un inicio rápido. También puedes investigar posibles optimizaciones dentro de JavaScript. Tal vez puedas hacer que JavaScript se ejecute más rápido. Tal vez puedas encontrar formas de precompilar JavaScript. Creo que, sabes, lo hemos estado tratando como una caja negra. Pero creo que hay posibilidades que realmente podemos utilizar para hacer que CI sea un poco más rápido y más receptivo.

Sí, en cuanto a las pruebas, estoy de acuerdo. Creo que hay mucho que se puede hacer para optimizar. Entonces, en las pruebas, me pregunto cuáles son las otras tareas pesadas en ese proceso.

Sí, diría que las pruebas. El benchmarking es otro clásico, porque, nuevamente, con el benchmarking, tienes que ejecutar el código y mantenerlo. A menudo tienes que ejecutar el código varias veces. Muchos frameworks modernos de benchmarking realizan análisis estadístico. Por lo tanto, tienen que ejecutarlo un número estadísticamente significativo de veces. Y, ya sabes, si no hay una solución tan buena porque, nuevamente, es benchmarking. Pero creo que hay algunas técnicas que podemos tomar de grandes empresas. Por ejemplo, sé que en Facebook, solo ejecutan benchmarks y pruebas relevantes para el commit. Porque obviamente Facebook se ejecuta a la escala de Facebook y no se pueden ejecutar todas las pruebas que existen. Así que creo que realmente... Estamos muy emocionados de ver cómo otras personas abordan este problema. Y también estamos muy emocionados de mostrar a las personas nuestras soluciones a este problema.

Genial. Entonces, Sissy Miller pregunta, viniendo del mundo de PHP, Pest PHP está revolucionando el mundo de las pruebas allí y está haciendo que las pruebas sean mucho más rápidas. Pero le gustaría preguntar, o no, él o ella, no lo sé. ¿Estarías de acuerdo en que parte de la lentitud de CI se puede evitar con un código más limpio? Yo diría que sí. Por supuesto. Creo que, tanto un código más limpio en las herramientas como en tu código normal. Obviamente, si estás ejecutando el código, quieres que sea rápido y no lento. Y diría, desde mi perspectiva, como alguien que escribe herramientas, creo que eso es algo que se ha descuidado en el mundo de las herramientas: el rendimiento.

Optimización de rendimiento y menciones especiales

Short description:

Me gustaría hacer una mención especial a los autores de ESBuild y SWC por pensar en el rendimiento. Nuestros benchmarks son significativamente mejores ahora, alrededor del 20% al 30%. Siempre hay más rendimiento que se puede exprimir.

Y, sabes, me gustaría hacer una mención especial a muchas personas que están escribiendo herramientas y que piensan en el rendimiento de manera cuidadosa, como los autores de ESBuild y los autores de SWC. Nosotros en Roam, hemos puesto mucho esfuerzo en eso. De hecho, en realidad... Los benchmarks que les mostré en la charla están realmente desactualizados. Hemos estado haciendo muchas optimizaciones de rendimiento desde entonces, y diría que nuestros números son quizás un 20% o 30% mejores que eso, lo cual es un trabajo realmente fantástico. Y estoy muy emocionado de mostrar eso a la gente. Creo que, ya sabes- Eso es realmente genial. Sí, siempre hay más cosas que se pueden hacer. Siempre hay más rendimiento que se puede exprimir. Así que sí.

Optimización de rendimiento y herramientas rápidas

Short description:

En Roam, hemos implementado mejoras de rendimiento optimizando el proceso de análisis y minimizando el trabajo redundante en el formateo. Nuestro objetivo es hacer que el análisis sea más rápido reduciendo el retroceso cuando el analizador encuentra una construcción sintáctica diferente. Además, nos enfocamos en asegurar que el formateador realice solo las acciones necesarias sin reorganización innecesaria del texto. Las herramientas rápidas son esenciales no solo para CI, sino también para los desarrolladores que utilizan hardware más lento. No es justo escribir código que solo funcione en máquinas de alta gama.

Solo, supongo, compartir un poco. ¿Qué tipo de mejoras de rendimiento has implementado en Roam? Solo de lo que te acuerdes. Por ejemplo, una gran cosa que siempre tienes que hacer es analizar el código. Y el análisis es notoriamente lento por varias razones. Primero, tienes que leer el código de E/S. Y segundo, tienes que crear esta gran estructura de datos. Así que hemos estado trabajando mucho para básicamente asegurarnos de que cuando analices, estés haciendo la cantidad mínima de trabajo porque muchas veces puedes analizar algo y luego darte cuenta de que es una construcción sintáctica diferente. Por ejemplo, puedes estar analizando, tu analizador puede estar analizando algún código y darte cuenta, oh, espera un momento, no es una expresión JSX, es una aserción de tipo TypeScript. Porque resulta que estas dos cosas se ven muy, muy similares. Y hemos estado trabajando mucho en ese proceso donde el analizador se da cuenta de que es algo diferente a lo esperado. Tiene que retroceder. Estamos tratando de hacer eso menos y menos para que el análisis sea mucho, mucho más rápido.

También estamos trabajando mucho en el formateo, asegurándonos de que el formateador haga solo lo mínimo necesario. Y realmente no está haciendo trabajo redundante moviendo el texto y reorganizando el código.

Bueno, veo eso, gente, solo quiero animarlos a recordar sobre Slido, si quieren decirnos qué otras herramientas encuentran molestas y lentas, nos encantaría escuchar del 11% de ustedes. Y también qué IDE están usando. Nos encantaría saberlo. Y si responden a tiempo, tal vez Nicholas pueda darnos su opinión sobre por qué cree que esas herramientas específicas son lentas. Pero, quiero decir, desde mi perspectiva personal, no encuentro mi CI muy lento. Entonces, ¿por qué esto debería importar? ¿Por qué debería preocuparme por esto? Ese es un buen punto. Y, sabes, me alegra que tu CI no sea lento. Me alegra que, ya sabes, no estés esperando como otras personas. Diría que creo que las herramientas rápidas son universalmente algo bueno, incluso si no es para tu CI. Creo que, ya sabes, realmente, nuevamente debemos recordar que no todos están ejecutando, ya sabes, una computadora súper moderna. Como dije en la charla, ya sabes, nosotros, como desarrolladores en, ya sabes, empresas, obtenemos, ya sabes, hardware moderno, con bastante frecuencia. Pero, ya sabes, hay muchas personas por ahí que están comenzando, o tal vez en empresas que no tienen presupuesto y están ejecutando en hardware más lento y tenemos que adaptarnos a ellos. Creo que no es justo escribir código que solo funcione en, ya sabes, una nueva MacBook Pro. Tiene sentido. Eso es, ya sabes, sí. Sí, puedo apreciar eso, obviamente. Así que eso fue hablado desde lo más profundo de Turbulent.

Conexiones lentas a Internet y detalles del Linter

Short description:

Ejecutar código en conexiones lentas a Internet es una lección importante para los desarrolladores. Nuestro Linter se enfoca en las reglas más lentas en ESLint para proporcionar comentarios rápidos. Aunque actualmente no hay colaboración para compartir un solo AST entre las herramientas populares, el Proyecto TreeSitter es un ejemplo inspirador de un analizador que puede analizar varios lenguajes. Compartir AST requeriría cambios significativos. Cece Miller pregunta sobre la interpretación de código por IA, como GitHub Copilot.

Eso fue una de esas cosas, y yo pensé, vale. Sí, quiero decir, también he sido culpable de eso. Sabes, ejecuto el código y pienso, oh, es muy rápido, pero, sabes, creo que olvidé qué compañía era, pero tenían la costumbre de básicamente ralentizar su conexión a Internet, como limitarla con el propósito expreso de adaptarse a personas que están en, como, una conexión 3G o incluso 2G, porque creo que es una lección realmente, sabes, importante para dar a los desarrolladores.

Sí, eso es muy cierto. Dainy pregunta, ¿puedes compartir algunos detalles sobre el Linter? ¿Cómo se comparará con ESLint en términos de reglas, complementos y otros factores? Sí, estoy realmente emocionado por esto porque el Linting es algo que, sabes, ha sido lento durante un tiempo. Y obviamente, ESLint es un proyecto fantástico, y tienen muchas reglas, y no voy a decir que vamos a capturar todas estas reglas de una vez, porque, sabes, como todos siempre me dicen todo el tiempo, Roma no se construyó en un día. Así que diría que nos estamos enfocando en cuáles son las reglas más lentas en ESLint, qué cosas realmente lo hacen doloroso, y luego vamos a construir un Linter para esas reglas específicas. Y luego, sabes, la idea tal vez es que puedes ejecutar nuestro Linter, obtener comentarios rápidos para ciertas cosas. Y si quieres una configuración completa de Linting, aún puedes ejecutar ESLint, y aún puedes obtener todos los comentarios de ESLint, pero obtendrás los comentarios rápidos primero.

Eso es genial. Entonces, Nicholas, alguien, J. Reid, está diciendo, Nicholas mencionó que algunas de las varias herramientas en el ecosistema de JS, el ecosistema de JavaScript, tienen que construir sus propios AST. Disculpas, no sé qué significa AST, para hacer su trabajo. ¿Alguien sabe si hay alguna colaboración entre algunas de las herramientas más populares con el objetivo de compartir un solo AST? Solo dime qué es un AST rápidamente. Árbol de Sintaxis Abstracta. Sí, es lo que el analizador produce. Sí, y que yo sepa, no creo que haya. Quiero decir, podría estar equivocado, y estoy dispuesto a que me demuestren lo contrario, porque creo que sería un gran proyecto. Una cosa que encuentro realmente inspiradora es el Proyecto TreeSitter, que es un analizador que básicamente puede analizar varios lenguajes diferentes, prácticamente cualquier lenguaje que puedas pensar tiene un analizador de TreeSitter, incluido JavaScript. Y eso es un gran ejemplo de básicamente alguien escribiendo un gran analizador, que luego muchas personas pueden usar. No estoy muy seguro si actualmente hay alguna forma de compartir el AST. Quiero decir, obviamente hay algunos problemas con si una herramienta cambia el AST, entonces las otras herramientas no pueden usar el mismo AST. Así que es un poco complicado. Y no estoy seguro de que eso funcionaría necesariamente sin algunos cambios importantes. Genial. Gracias. Esa fue una... esa fue una muy buena respuesta. Cece Miller hace otra pregunta. ¿Has investigado sobre la interpretación de código por IA, como GitHub Copilot? Tal vez esto podría llevarlo a otro nivel.

ML and Parser Error Recovery

Short description:

He probado Tab 9 y Copilot, y me parecen proyectos realmente geniales. Aunque Roam no se dirige actualmente en esa dirección, estamos abiertos a explorar la combinación de aprendizaje automático y código en el futuro. Una de las áreas que estamos considerando es el uso del aprendizaje automático para la recuperación de errores del analizador, aprovechando conjuntos de datos de código incorrecto para estimar el código previsto y ofrecer correcciones o un mejor análisis semántico. En cuanto al soporte de reglas personalizadas del linter, todavía estamos trabajando en eso. Nuestro objetivo es proporcionar una amplia variedad de reglas, pero reconocemos la próspera comunidad de eswint.

Personalmente, he probado ambos. También soy un gran fan de Tab 9 y Copilot. Creo que son proyectos realmente geniales. Sí, Tab 9 es un proyecto fantástico. No diría que esa es necesariamente la dirección que estamos tomando en Roam en este momento. Creo que definitivamente es algo que estamos abiertos a explorar en el futuro. Quiero decir, creo que la combinación de aprendizaje automático y código es un área realmente fascinante que sin duda se desarrollará más en los próximos años.

Creo que una cosa en la que hemos investigado y que he estado considerando es tal vez utilizar el aprendizaje automático para la recuperación de errores del analizador. Como mencioné en la charla, una gran ventaja de nuestro analizador es que tiene una muy buena recuperación de errores. Básicamente, puede detectar cuando hay un error e intentar adivinar qué quisiste decir con eso. Y actualmente lo hacemos con algunas heurísticas, pero creo que en el futuro podría ser una oportunidad realmente interesante para el aprendizaje automático donde puedes utilizar conjuntos de datos de código incorrecto para estimar cuál es el código previsto y luego ofrecer una corrección o un mejor análisis semántico. Sí, eso tiene sentido. Forlex, no sé si es Forlex o si es Leap para Alex, pero pregunta cómo se manejarán todas esas reglas personalizadas del linter que vienen con otras bibliotecas de forma gratuita como lint, ¿cómo las van a soportar? Esa es una muy buena pregunta. Voy a ser honesto, todavía estamos tratando de resolver eso nosotros mismos. Creo que, nuevamente, tenemos esta idea de que R12 es como el explorador que va un poco adelante. Y, ya sabes, si nuestras reglas son incorrectas debes corregirlas primero. Y luego, si nuestras reglas son todas, ya sabes, válidas y el código es correcto para estas reglas entonces puedes ejecutar eswint y obtener la completitud total. No, ya sabes, creo que haremos nuestro mejor esfuerzo para ofrecer una amplia variedad de reglas y seguiremos agregando más pero la realidad es que eswint, ya sabes, hace un trabajo maravilloso y también es una comunidad muy próspera. Y, ya sabes, tenemos que reconocer eso. Sí. Genial. Estás recibiendo comentarios realmente buenos aquí. Solo quiero decirte que lo que piensa la comunidad son ideas realmente buenas de tu compañero en la sala de discusión, en la sala de construcción, Ante Tomić. Ideas realmente buenas. Está interesado en Rome, quiere echarle un vistazo y hay muchos comentarios realmente buenos sobre la charla. No veo, ahora es el momento, esto es todo. Estamos llegando al final. Haz tus últimas preguntas a Nicholas. De lo contrario, nos uniremos a Nicholas y a nuestros compañeros presentadores para una breve charla junto al fuego.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
End the Pain: Rethinking CI for Large Monorepos
Scaling large codebases, especially monorepos, can be a nightmare on Continuous Integration (CI) systems. The current landscape of CI tools leans towards being machine-oriented, low-level, and demanding in terms of maintenance. What's worse, they're often disassociated from the developer's actual needs and workflow.Why is CI a stumbling block? Because current CI systems are jacks-of-all-trades, with no specific understanding of your codebase. They can't take advantage of the context they operate in to offer optimizations.In this talk, we'll explore the future of CI, designed specifically for large codebases and monorepos. Imagine a CI system that understands the structure of your workspace, dynamically parallelizes tasks across machines using historical data, and does all of this with a minimal, high-level configuration. Let's rethink CI, making it smarter, more efficient, and aligned with developer needs.
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Atomic Deployment for JS Hipsters
Deploying an app is all but an easy process. You will encounter a lot of glitches and pain points to solve to have it working properly. The worst is: that now that you can deploy your app in production, how can't you also deploy all branches in the project to get access to live previews? And be able to do a fast-revert on-demand?Fortunately, the classic DevOps toolkit has all you need to achieve it without compromising your mental health. By expertly mixing Git, Unix tools, and API calls, and orchestrating all of them with JavaScript, you'll master the secret of safe atomic deployments.No more need to rely on commercial services: become the perfect tool master and netlifize your app right at home!

Workshops on related topic

DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.
DevOps.js Conf 2022DevOps.js Conf 2022
163 min
How to develop, build, and deploy Node.js microservices with Pulumi and Azure DevOps
Workshop
The workshop gives a practical perspective of key principles needed to develop, build, and maintain a set of microservices in the Node.js stack. It covers specifics of creating isolated TypeScript services using the monorepo approach with lerna and yarn workspaces. The workshop includes an overview and a live exercise to create cloud environment with Pulumi framework and Azure services. The sessions fits the best developers who want to learn and practice build and deploy techniques using Azure stack and Pulumi for Node.js.