Master

Herramientas

Adoptar?

  • Sentry se ha convertido en la elección predeterminada para muchos de nuestros equipos a la hora de reportar errores de frontend. La utilidad de características como la agrupación de errores o poder definir patrones para descartar errores con ciertos parámetros ayuda a gestionar la avalancha de errores que llegan de muchos dispositivos de usuarios finales. La integración de Sentry en el pipeline de despliegue continuo permite cargar mapas de orígenes para una depuración de errores más eficiente. Aunque Sentry se ofrece principalmente como un SaaS, también valoramos que su código fuente está disponible públicamente y se puede usar gratis en casos de uso más pequeños y en instalaciones auto-hospedadas.

    Historia

Probar?

  • Hacer que la web sea inclusiva requiere de mucha atención para asegurar que la accesibilidad sea considerada y validada durante todas las fases de la entrega de software. Muchas de las herramientas populares para pruebas de accesibilidad son diseñadas para efectuar sus validaciones una vez que la aplicación está completa; como resultado, los problemas se detectan tarde y a menudo se dificulta su corrección, por lo que se acumulan como deuda. En nuestro reciente trabajo interno en los sitios web de Thoughtworks, hemos incluido como parte del pipeline a axe-core, un motor de pruebas de accesibilidad de software libre. Empezó a proporcionar una retroalimentación temprana a los miembros del equipo sobre la adherencia a las reglas de accesibilidad, incluso durante las primeras adiciones incrementales de funcionalidad. Sin embargo, no todos los problemas pueden ser encontrados mediante la inspección automatizada. Para extender a axe-core, existe la herramienta comercial axe DevTools, que incluye características que guían a los miembros del equipo en la realización de pruebas exploratorias para la mayoría de problemas de accesibilidad.

    Historia
  • Desde la última vez que escribimos sobre dbt, lo hemos utilizado en algunos proyectos y nos gusta lo que hemos visto. Por ejemplo, dbt hace que la parte de transformación de los pipelines ETL sea más accesible para los consumidores de los datos en vez de solo para los ingenieros de datos que los construyen. Al mismo tiempo, fomenta la aplicación de buenas prácticas de ingeniería, como el versionamiento, las pruebas automatizadas y los despliegues. SQL sigue siendo la lengua franca del mundo de los datos (incluyendo bases de datos, almacenes de datos, motores de consulta, lagos de datos y plataformas de analítica) y la mayoría de estos sistemas lo soportan en cierta medida. Esto permite que dbt sea utilizado frente a estos sistemas para realizar transformaciones con la sola construcción de adaptadores. El número de conectores nativos ha crecido e incluyen aquellos para Snowflake, BigQuery, Redshift y Postgres, al igual que la gama de complementos de la comunidad. Vemos que las herramientas como dbt ayudan a que las plataformas de datos brinden más capacidades de auto-servicio.

    Historia
  • Siempre nos ha llamado la atención encontrar herramientas que puedan acortar el ciclo de retroalimentación en el desarrollo de software, y esbuild es un buen ejemplo. A medida que la base de código de una aplicación de front-end crece más y más, generalmente experimentamos tiempos de empaquetado que se cuentan en minutos. esbuild, como un empaquetador de JavaScript optimizado para proveer mayor velocidad, puede reducir estos tiempos en factores de 10 a 100. Está escrito en Golang y utiliza un enfoque más eficiente en los procesos de análisis sintáctico, escritura y generación de mapas de código fuente, que superan significativamente a los de herramientas como Webpack y Parcel. Puede ser que esbuild no sea tan completa como esas herramientas para la transformación de sintaxis de JavaScript, sin embargo esto no impide que muchos de nuestros equipos se cambien a esbuild y la usen como su herramienta preferida.

    Historia
  • Flipper es un depurador extensible para aplicaciones móviles. De manera predeterminada, soporta la elaboración de perfiles, inspeccion interactiva del diseño, visor de registros y un inspector de red para aplicaciones iOS, Android y React Native. En comparación a otras herramientas de depuración para aplicaciones móviles, encontramos que Flipper es ligero, tiene valiosas características y es de fácil configuración.

    Historia
  • Habíamos escrito sobre Great Expectations en la edición anterior del Radar. Nos encanta y hemos decidido moverlo al anillo "Probar" en esta edición. Great Expectations es un marco de trabajo que permite crear controles que etiquetan anomalías o problemas de calidad en los pipelines de datos. Igual que la ejecución de una prueba unitaria en un pipeline de compilación, Great Expectations realiza verificaciones durante la ejecución del pipeline de datos. Nos gusta su simplicidad y facilidad de uso: las reglas almacenadas en formato JSON pueden ser modificadas por nuestros expertos del dominio de datos sin necesidad de tener habilidades de ingeniería de datos.

    Historia
  • Hemos trabajado un poco más en pruebas de rendimiento con k6 desde que lo cubrimos por primera vez en el Radar, y hemos conseguido buenos resultados. Nuestros equipos han apreciado el enfoque en la experiencia para las desarrolladoras y la flexibilidad de la herramienta. Aunque es fácil comenzar con k6 por sí solo, realmente destaca por su facilidad de integración en un ecosistema de desarrollo. Por ejemplo, utilizando el adaptador Datadog, un equipo pudo visualizar rápidamente el rendimiento en un sistema distribuido e identificar importantes problemas antes de lanzar el sistema a producción. Otro equipo, con la versión comercial de k6, pudo usar la extensión de Azure pipelines marketplace para realizar pruebas de rendimiento en su pipeline de integración continua y obtener informes de Azure DevOps con poco esfuerzo. Dado que k6 admite umbrales que permiten tener verificaciones de pruebas automatizadas listas para usar, es relativamente fácil agregar una etapa al pipeline que detecte la degradación del rendimiento de los nuevos cambios, agregando un poderoso mecanismo de retroalimentación para el equipo de desarrollo.

    Historia
  • MLflow es una herramienta de código abierto para el seguimiento de experimentos de aprendizaje automático y la gestión del ciclo de vida. El flujo de trabajo para desarrollar y evolucionar continuamente un modelo de aprendizaje automático incluye una serie de experimentos (una colección de ejecuciones), el seguimiento del rendimiento de estos experimentos (una colección de métricas) y el seguimiento y ajuste de modelos (proyectos). MLflow facilita este flujo de trabajo muy bien al apoyar los estándares abiertos existentes y se integra bien con muchas otras herramientas en el ecosistema. MLflow, como servicio gestionado por Databricks en la nube, disponible en AWS y Azure, está madurando rápidamente y lo hemos utilizado con éxito en nuestros proyectos. Consideramos que MLflow es una gran herramienta para la gestión y el seguimiento de modelos, que soporta tanto modelos de interacción basados en UI como en API. Nuestra única y creciente preocupación es que MLflow está tratando de entregar respuestas a demasiados temas vinculados, como una sola plataforma, como el servicio de modelos y la puntuación.

    Historia
  • OR-Tools es una suite de software de código abierto para resolver problemas de optimización combinatoria. Estos problemas de optimización tienen un conjunto muy grande de posibles soluciones y las herramientas como OR-Tools son de gran ayuda para buscar la mejor solución. Se puede modelar el problema en cualquiera de los lenguajes soportados (Python, Java, C# o C++) y elegir el solucionador de entre los muchos solucionadores soportados, tanto de código abierto como comerciales. Hemos usado con éxito OR-Tools en muchos proyectos de optimización con programación de enteros y de enteros mixta.

    Historia
  • Con Playwright es posible escribir pruebas de interfaz de usuario web para Chromium, Firefox y Webkit, todas a través de la misma API. Esta herramienta ha obtenido notoriedad gracias a su compatibilidad con los principales motores de navegación, que consigue por incluir versiones adaptadas de Firefox y Webkit. Seguimos recibiendo informes de experiencias positivas, sobre todo en cuanto a su estabilidad. Además, algunos equipos han podido migrar fácilmente de Puppeteer, que presenta una API muy similar.

    Historia
  • Nos complace ver que la disponibilidad y madurez de herramientas para el análisis de la configuración de la infraestructura ha aumentado: Prowler ayuda a los equipos a escanear sus configuraciones de infraestructura de AWS y a mejorar la seguridad en función de los resultados. Aunque Prowler ha estado presente por un tiempo, ha evolucionado mucho en los últimos años, y encontramos muy valioso que permite a los equipos asumir responsabilidades para alcanzar niveles apropiados de seguridad con ciclos cortos de retroalimentación. Prowler clasifica a las verificaciones del AWS CIS benchmarking en diferentes grupos (Identity and Access Management, Logging, Monitoring, Networking, CIS Level 1, CIS Level 2, EKS-CIS) e incluye numerosas validaciones que permiten comprender mejor aspectos sobre el cumplimiento de las normativas PCI DSS y GDPR.

    Historia
  • Aunque el duck typing es visto como una ventaja por muchas personas programadoras de Python, algunas veces, especialmente en grandes repositorios de código, la verificación de tipado también puede ser útil. Por esa razón, algunas anotaciones de tipos han sido incluidas en las Propuestas de Mejora de Python (Python Enhancement Proposals, PEP) y Pyright es un verificador para dichas anotaciones. Además, proporciona algun nivel de inferencia de tipos y protecciones que son capaces de entender código con estructuras condicionales. Diseñado pensando en grandes repositorios de código, Pyright es rápido y sus verificaciones en modo observador suceden incrementalmente a medida que los archivos cambian para disminuir aún más los ciclos de retroalimentación. Pyright puede usarse directamente en la línea de comandos y también existen integraciones disponibles para VS Code, Emacs, vim, Sublime y posiblemente otros editores. En nuestra experiencia, Pyright es mejor que alternativas como mypy.

    Historia
  • Adoptar una filosofía de DevOps del estilo "tú lo construyes, tú lo ejecutas" significa que los equipos deben prestar más atención a las métricas técnicas como a las de negocio, las cuales pueden ser tomadas de los sistemas que despliegan. A menudo vemos que las herramientas para analíticas son difíciles de usar para la mayoría de las desarrolladoras, así que la tarea de capturar y presentar métricas queda para otros equipos, incluso tiempo después de que las funcionalidades han sido entregadas a los usuarios finales. Nuestros equipos encontraron que Redash es muy útil para consultar métricas del producto y para crear paneles y tableros, en formas que pueden ser autogestionadas por la mayoría de las desarrolladoras, acortando los ciclos de retroalimentación y enfocando al equipo en los resultados del negocio.

    Historia
  • Terratest nos llamó la atención en el pasado como una opción interesante para pruebas de infraestructura. Desde entonces, nuestros equipos lo han utilizado y están muy entusiasmados por su estabilidad y la experiencia que proporciona. Terratest es una biblioteca de Golang que hace más fácil escribir pruebas automáticas para el código de infraestructura. Utilizando herramientas de infraestructura como código, como Terraform, es posible crear componentes de infraestructura reales (como servidores, firewalls o balanceadores de carga) para desplegar aplicaciones en ellos y después validar el comportamiento esperado utilizando Terratest. Al finalizar las pruebas, Terratest puede retirar las aplicaciones y limpiar los recursos. Esto lo hace muy útil para pruebas de infraestructura de extremo a extremo en un entorno real.

    Historia
  • Tuple es una herramienta relativamente nueva optimizada para la programación en pareja en remoto, diseñada para llenar el vacío que dejó Slack en el mercado después de abandonar a Screenhero. Aunque todavía presenta algunos problemas por su crecimiento (por ejemplo, su disponibilidad está limitada a macOS por ahora, con el soporte para Linux próximamente, y tiene algunas anomalías por resolver en su interfaz de usuario), hemos tenido una buena experiencia usándola dentro de esas restricciones. A diferencia de las herramientas de videoconferencia de propósito más general con capacidades para compartir pantallas, como Zoom, Tuple permite el control dual mediante dos cursores de ratón y, a diferencia de opciones como Visual Studio Live Share, no está vinculado a un IDE. Tuple admite llamadas de voz y video, uso compartido de portapapeles y menor latencia que las herramientas comunes. La capacidad de Tuple para permitir dibujar y borrar con facilidad en la pantalla de la pareja hace sea una herramienta muy intuitiva y de fácil manejo para las personas desarrolladoras.

    Historia
  • Al trabajar con React, a menudo nos encontramos con situaciones en las cuales una página se ralentiza debido a que ciertos componentes se están volviendo a renderizar cuando no deberían. Why Did You Render es una libería que ayuda a detectar por qué un componente se está volviendo a renderizar; lo consigue al modificar el comportamiento del código en tiempo de ejecución mediante monkey patching React. Nosotros lo hemos utilizado con gran efectividad en algunos de nuestros proyectos para investigar problemas de rendimiento.

    Historia

Evaluar?

  • A pesar de que Docker se ha convertido en una elección razonable predeterminada para contenerización, vemos que hay nuevos actores en este espacio llamando la atención. Ese es el caso de Buildah y Podman, que son proyectos complementarios para construir imágenes (Buildah) y correr contenedores (Podman) sin privilegios de usuario root en multiples distribuciones de Linux. Podman presenta un motor sin procesos demonios para manejar y correr los contenedores, lo que es una propuesta interesante en comparación a lo que hace Docker. El hecho de que Podman puede usar ya sea imágenes de tipo Open Container Initiative (OCI) construidas por Buildah o imágenes Docker, hacen de esta herramienta atractiva y fácil de usar.

    Historia
  • Los servidores de integración contínua (CI) y las herramientas de compilación son algunos de los elementos más antiguos y más usados de nuestro kit. Cubren toda la gama, desde simples servicios alojados en la nube hasta complejos servidores de pipelines definidos por código soportados por flotas de agentes de compilación. Dada nuestra experiencia y la amplia gama de opciones disponibles, inicialmente estábamos escépticos cuando GitHub Actions fue presentado como otro mecanismo para administrar los procesos de compilación e integración. Pero la oportunidad para que las desarrolladoras comiencen con algo pequeño y personalicen fácilmente el comportamiento significa que GitHub Actions se está volviendo la opción predeterminada para los proyectos más pequeños. Es difícil discutir la conveniencia de tener la herramienta de compilación integrada directamente en el repositorio de código fuente. Ha surgido una comunidad entusiasta en torno a esta función y eso significa que existe una amplia gama de herramientas y flujos de trabajo aportados por los usuarios para comenzar. Los proveedores de herramientas también se están incorporando a través del GitHub Marketplace. Sin embargo, recomendamos proceder con cautela. Aunque el código y el historial de Git se pueden exportar a servicios alternos, no se puede hacer lo mismo con un flujo de trabajo de desarrollo basado en GitHub Actions. Además, es necesario usar el mejor criterio para determinar cuándo un proyecto es lo suficientemente grande o complejo como para justificar una herramienta de pipelines con soporte independiente. Sin embargo, para comenzar a trabajar rápidamente en proyectos más pequeños, vale la pena considerar GitHub Actions y el ecosistema que está creciendo a su alrededor.

    Historia
  • La Imagen Nativa de Graal es una tecnología que compila código Java en un binario nativo de un sistema operativo, en la forma de un ejecutable enlazado estáticamente o de una biblioteca compartida. Una imagen nativa está optimizada para reducir la huella de memoria y el tiempo de inicio de una aplicación. Nuestros equipos han usado con éxito las imágenes nativas de Graal, ejecutándolas como pequeños contenedores Docker, en la arquitectura sin servidor (serverless architecture) donde reducir el tiempo de inicio es importante. Aunque se diseñó para utilizarse con lenguajes de programación como Go o Rust que se compilan nativamente y requieren de tamaños pequeños de binarios y de tiempos de inicio cortos, la imagen nativa de Graal puede ser igualmente útil para equipos que tienen otros requerimientos y que quieren usar lenguajes basados en la JVM.

    El generador de imágenes nativas de Graal, native-image, soporta lenguajes basados en la JVM, como Java, Scala, Clojure y Kotlin, y genera ejecutables para múltiples sistemas operativos como macOS, Windows y varias distribuciones de Linux. Ya que se trabaja en un "mundo" que se asume "cerrado", donde todo el código se conoce en tiempo de compilación, se necesitan configuraciones adicionales para que características como la reflexión o la carga dinámica de clases funcionen, ya que no se pueden deducir los tipos en tiempo de compilación a partir del código mismo.

    Historia
  • HashiCorp Boundary combina las capacidades de gestión de identidad y redes seguras necesarias para la intermediación del acceso a sus hosts y servicios en un solo lugar y en una combinación de nube y recursos locales si es necesario. La administración de claves se puede realizar integrando cualquier servicio de administración de claves, ya sea de un proveedor en la nube o algo como HashiCorp Vault. HashiCorp Boundary admite un número creciente de proveedores de identidad que pueden integrarse con partes de su entorno de servicios para ayudar a definir los permisos, no solo en el host sino también a nivel de servicio. Por ejemplo, permite controlar el acceso detallado a un clúster de Kubernetes y la obtención de catálogos de servicios de forma dinámica de diversas fuentes es algo que está en el radar. Todo esto queda fuera del camino de los usuarios finales de ingeniería que obtienen la experiencia de línea de comandos a la que están acostumbrados, conectados de forma segura a través de la capa de administración de red del Boundary.

    Historia
  • ¿Recuerdan el proyecto pix2code que mostraba cómo generar código automáticamente a partir de las capturas de pantallas de una interfaz gráfica? Ahora existe una versión en forma de producto de esta técnica llamada imgcook, un producto SaaS de Alibaba que permite transformar archivos de diseño (Sketch, PSD, imágenes estáticas) a código front-end de manera inteligente. Alibaba necesita personalizar muchas páginas de campañas durante su festival de compras llamado 11:11. Generalmente, son pantallas de un solo uso que deben ser construidas rápidamente. A través de un método de aprendizaje profundo, el diseño de la experiencia de usuario es primero procesado a código front-end y luego es ajustado por alguna desarrolladora. Nuestro equipo está evaluando esta tecnología: aunque el procesamiento de imágenes se realiza en el lado del servidor y la interfaz principal está en la web, imgcook provee herramientas que se pueden integrar en el ciclo de diseño y desarrollo, además, puede generar código estático y también código de enlace a datos si se define un DSL. Esta tecnología no es perfecta aún, las diseñadoras deben sujetarse a ciertas especificaciones para mejorar la precisión de la generación del código (que de todas maneras deberá ser ajustado por las desarrolladoras después). Siempre hemos sido cautelosos con la generación "mágica" de código, porque generalmente suele ser un código difícil de mantener a largo plazo e imgcook no es la excepción. Pero si se limita su uso a un contexto específico, como páginas de campañas de un solo uso, vale la pena probarlo.

    Historia
  • Longhorn es un sistema distribuido de almacenamiento en bloques para Kubernetes. Hay muchas opciones para el almacenamiento persistente para Kubernetes, pero a diferencia de la mayoría, Longhorn está construido desde cero para proveer instantáneas y copias de seguridad incrementales, reduciendo las molestias de poner en marcha un almacenamiento replicado para instancias de Kubernetes que no están alojadas en la nube. Con el reciente soporte experimental para ReadWriteMany (RWX) incluso se puede montar un mismo volumen para lectura y para escritura a través de distintos nodos. Escoger el sistema de almacenamiento correcto para Kubernetes no es tarea fácil y recomendamos evaluar Longhorn en función de tus necesidades.

    Historia
  • Operator Framework es un conjunto de herramientas de código abierto que simplifica la construcción y la administración del ciclo de vida de Kubernetes operators. El patrón operador de Kubernetes, originalmente introducido por CoreOS, es un enfoque para encapsular el conocimiento de operar una aplicación utilizando las capacidades nativas de Kubernetes; incluye resources para gestionar y controller code que garantiza que los recursos coincidan con el estado esperado. Este enfoque ha sido usado para ampliar Kubernetes y administrar varias aplicaciones de forma nativa, particularmente, las que manejan estado . Operator Framework cuenta con tres componentes: Operator SDK, que simplifica la construcción, pruebas y empaquetamiento de operadores Kubernetes; Operator lifecycle manager para instalar, administrar y actualizar los operadores; y un catalog para publicar y compartir operadores de terceros. Nuestros equipos han descubierto que Operator SDK es particularmente poderoso para desarrollar rápidamente aplicaciones nativas de Kubernetes.

    Historia
  • El número de servicios ofrecidos por los proveedores grandes de la nube continúa creciendo, y también lo hace la conveniencia y la madurez de las herramientas que ayudan a usarlos de manera segura y eficiente. Recommender es un servicio de Google Cloud que analiza los recursos que usas y ofrece recomendaciones de cómo optimizarlos en base al uso actual. El servicio consiste de una serie de "recomendadores" en áreas como seguridad, uso de cómputo o ahorro de costos. Por ejemplo, el IAM Recommender ayuda a implementar mejor el principio de menor privilegio señalando los permisos que nunca se han usado y que son potencialmente muy amplios.

    Historia
  • En los últimos años, el Windows Subsystem for Linux (WSL) ha sido mencionado algunas veces en nuestras discusiones. Aunque nos gustó lo que vimos, incluyendo las mejoras que introdujo WSL 2, no ha logrado entrar en el Radar. En esta edición queremos destacar una extensión para Visual Studio Code que ha mejorado en gran medida la experiencia de trabajo con WSL. Si bien los editores basados en Windows siempre podían acceder a los archivos del sistema de archivos de WSL, no sabían de la existencia de este entorno Linux aislado. Con la extensión Remote - WSL, Visual Studio Code se vuelve consciente de WSL, permitiendo a las personas desarrolladoras ejecutar un shell de Linux. Esta extensión también permite depurar binarios que se ejecutan dentro de WSL desde Windows. IntelliJ, de JetBrains, también ha trabajado en mejorar notablemente su soporte para WSL.

    Historia
  • Uno de los patrones que hemos visto repetirse en esta publicación es que las herramientas estáticas de comprobación de errores y estilo surgen rápidamente después de que un nuevo lenguaje gana popularidad. Estas herramientas se conocen genéricamente como linters, en honor a la clásica y querida utilidad lint de Unix, que analiza estáticamente el código C. Nos gustan estas herramientas porque detectan errores tempranamente, incluso antes de que se compile el código. La instancia más nueva de este patrón es Spectral, un linter para YAML y JSON. Aunque Spectral es una herramienta genérica para estos formatos, su principal objetivo es OpenAPI (la evolución de Swagger) y AsyncAPI. Spectral viene con un conjunto completo de reglas listas para usar para estas especificaciones que pueden ahorrarle dolores de cabeza a las personas desarrolladoras al diseñar e implementar APIs o colaboración basada en eventos. Estas reglas verifican las especificaciones adecuadas de los parámetros de la API o la existencia de una declaración de licencia en la especificación, entre otras cosas. Si bien esta herramienta es una adición bienvenida al flujo de trabajo de desarrollo de APIs, plantea la pregunta de si una especificación no ejecutable debe ser tan compleja como para requerir una técnica de verificación de errores diseñada para lenguajes de programación. ¿Quizás las personas desarrolladoras deberían escribir código en lugar de especificaciones?

    Historia
  • Yelp detect-secrets es un módulo de Python para detectar secretos dentro de una base de código fuente: analiza los archivos dentro de un directorio en búsqueda de secretos. Se puede utilizar con Git mediante un hook de pre-commit o como parte de un pipeline de CI/CD para realizar un escaneo en múltiples ubicaciones. Viene con una configuración predeterminada que simplifica su uso, y también puede ser modificada para adaptarse a diversas necesidades. También se pueden instalar complementos personalizados y añadirlos a sus búsquedas heurísticas predeterminadas. En comparación con ofertas similares, descubrimos que esta herramienta detecta más tipos de secretos con sus configuraciones predeterminadas.

    Historia
  • A medida que madura el ecosistema para la especificación de APIs, estamos viendo que aparecen más herramientas para automatizar la validación de estilos. Zally es un linter minimalista para OpenAPI que ayuda a garantizar que un API se ajusta a la guía de estilo utilizada por el equipo. De manera predeterminada, esta herramienta validará usando las reglas desarrolladas para la guía de estilos de Zalando, pero también soporta un mecanismo de extensión basado en Kotlin para la creación de reglas personalizadas. Zally incluye una interfaz de usuario web muy intuitiva para comprender las violaciones a las reglas de estilos e incluye una interfaz de línea de comando (CLI) que hace fácil su integración a los pipelines de CD.

    Historia

Resistir?

  • En base a la experiencia de múltiples equipos de Thoughtworks, sugerimos tener cuidado al considerar el uso de AWS CodePipeline. Específicamente, hemos notado que una vez que los equipos evolucionan y necesitan pipelines algo más complejos, esta herramienta puede empezar a ser difícil de usar. A pesar de que su uso podría parecer como una victoria rápida al comenzar con AWS, les aconsejamos dar un paso atrás y revisar con detenimiento si AWS CodePipeline ayudará a solventar algunas necesidades que podrían aparecer a largo plazo, como por ejemplo, flujos con tareas paralelas (pipeline fan-out & fan-in) o escenarios más complejos de despliegues y de ejecución de pruebas, que hacen uso de dependencias y activadores (triggers) no triviales.

    Historia
¿No encuentras aquello que querías ver?

Cada edición del Radar incluye blips que contienen la información encontrada durante los últimos seis meses. Es posible que ya hayamos incluido el tema que estás buscando en Radares anteriores. Hay veces que omitimos algunos temas debido a que hay demasiado de que hablar. O también, puede faltar algo debido a que en el Radar buscamos reflejar nuestra experiencia, no lo basamos en un análisis exhaustivo del mercado.

Nuevo,Modificado,Ningún cambio