Menú

Técnicas

Adoptar?

  • Cada vez más empresas están construyendo plataformas internas para desplegar nuevas soluciones digitales de forma rápida y eficiente. Las compañías que tienen éxito con esta estrategia están aplicando técnicas de gestión de producto a plataformas internas. Esto significa establecer empatía con los clientes internos (los equipos de desarrollo) y colaborar con ellos en el diseño. Los gerentes de producto de plataforma crean hojas de ruta y se aseguran que la plataforma entrega valor al negocio y mejora la experiencia de los interesados. Desafortunadamente, estamos viendo estrategias menos exitosas, donde los equipos crean plataformas en el vacío, basándose en supuestos no verificados y sin clientes internos. Estas plataformas, a menudo, y a pesar de agresivas tácticas internas, terminan por ser subutilizadas y reducen la capacidad de entrega de la empresa. Como es habitual, una buena gestión de producto trata de conseguir construir productos que encantan a los consumidores.

    Historia
  • Aunque la infraestructura como código es una técnica relativamente antigua (la expusimos en el Radar en el 2011) se ha vuelto vitalmente importante en la era moderna de la nube, donde el acto de configurar la infraestructura se ha convertido en el paso de instrucciones de configuración a una plataforma en la nube. Cuando decimos “como código”, significa que todas las buenas prácticas que hemos aprendido en el mundo del software deberían ser aplicadas a la infraestructura. El uso del control de versiones, adherirnos al principio DRY, modularización, mantenibilidad, y el uso de pruebas y despliegues automatizados son todas prácticas críticas. Aquellos de nosotros con fuerte trasfondo de software e infraestructura necesitamos empatizar y ayudar a los colegas que no lo tengan. Decir “tratemos la infraestructura como código” no es suficiente, necesitamos asegurarnos de que los aprendizajes que nos costaron tanto obtener del mundo del software sean también aplicados consistentemente a lo largo del dominio de la infraestructura.

    Historia
  • Hemos visto beneficios significativos al utilizar microservicios, que han permitido a los equipos escalar la entrega de servicios desplegados y mantenidos de manera independiente. Desafortunadamente, también hemos visto a equipos crear frontends monolíticos (aplicaciones web grandes y complejas sobre servicios del backend) que neutralizan en gran parte los beneficios de los microservicios. Los micro frontends continúan ganando popularidad desde que se introdujeron por primera vez. Hemos visto a muchos equipos adoptar de una u otra forma esta arquitectura para manejar la complejidad de múltiples personas desarrolladoras y equipos contribuyendo en la misma experiencia de usuario. En junio del año pasado, uno de los autores de esta técnica publicó un artículo introductorio que sirve de referencia para los micro frontends. Este artículo muestra cómo se puede implementar este estilo utilizando varios mecanismos de programación web e indica un ejemplo usando React.js. Confiamos en que este estilo crecerá en popularidad a medida que las organizaciones dividan

    Historia
  • La técnica de Pipelines como código enfatiza que la configuración de los pipelines de entrega que se encargan de construir, probar y desplegar nuestras aplicaciones o infraestructura deben crearse como código; deben colocarse bajo control de código fuente y modularizarse en componentes reutilizables con pruebas y despliegue automatizados. A medida que las organizaciones se trasladan a la creación de equipos autónomos descentralizados microservicios o micro frontends, La necesidad de prácticas de ingeniería en la gestión de pipelines como codigo aumenta para mantener la construcción y la implementación de software coherente dentro de la organización. Esta necesidad ha dado lugar a la entrega de plantillas de pipelines y herramientas que permitan una forma estandarizada de construir, desplegar servicios y aplicaciones. Dichas herramientas utilizan pipelines de entrega declarativos de aplicaciones adoptando un plan de pipelines para ejecutar las tareas subyacentes y las diversas etapas de un ciclo de vida de entrega, como compilación, prueba y despliegue; y que además abstraen los detalles de implementación. La capacidad de construir, probar y desplegar pipelines como código debería ser uno de los criterios de evaluación para elegir una herramienta de CI/CD.

    Historia
  • Estamos convencidos que la programación en pares mejora la calidad del código, difunde el conocimiento entre el equipo y sobre todo permite una entrega de software más rápida. Sin embargo, en un mundo post COVID-19, muchos equipos de desarrollo de software se encontrarán geográficamente distribuidos o completamente remotos. En esta situación recomendamos trabajar en pares de forma remota y pragmática : ajustar las prácticas de trabajo en pares lo mejor posible con las herramientas disponibles a mano. Considera a herramientas como Visual Studio Live Share para colaborar eficientemente y con baja latencia. Recurre a la compartición de pantalla si ambos participantes residen en una zona geográficamente próxima y disponen de conexiones de internet suficientemente buenas. Emplea la programación en pares entre personas que se encuentren en zonas horarias similares en vez de esperar que esta técnica funcione para todas las personas sin importar su ubicación. Si el trabajo en pares no funciona debido a razones logísticas, recurre a prácticas tales como la programación individual aumentada con revisiones de código, colaboración a través de pull-requests (pero evitando tener ramas de larga duración con Gitflow) o ten sesiones muy cortas de trabajo en pares para hacer frente a secciones críticas del programa. Nos hemos dedicado al trabajo en pares remotos por ya bastante tiempo y hemos encontrado que es efectivo si se realiza con una dosis de pragmatismo.

    Historia
  • Desafortunadamente, los feature toggles son menos comunes de lo que nos gustaría, y, con frecuencia, vemos personas mezclando sus tipos y casos de uso. Es bastante común encontrarse con equipos que utilizan plataformas muy pesadas como LaunchDarkly para implementarlos, inclusive release toggles, para beneficiarse de la integración continua, cuando todo lo que necesitan son condiciones if/else. Por lo tanto, a menos que necesites realizar pruebas A/B o canary releases o entregar la responsabilidad de la liberación de funcionalidades a la gente de negocios, te recomendamos usar los feature toggles más simples posibles en vez de usar herramientas innecesariamente complejas.

    Historia

Probar?

  • Aplicar aprendizaje automático para hacer inteligentes a las aplicaciones y servicios de negocio no es solo entrenar modelos y servirlos. Requiere implementar, de principio a fin y continuamente, ciclos de entrenamiento, pruebas, despliegues, monitoreo y operación de los modelos. La entrega continua para aprendizaje automático (CD4ML) es una técnica que habilita la realización de ciclos fiables, de principio a fin, de desarrollo, despliegue y monitoreo de modelos de aprendizaje automático. La tecnología subyacente sobre la que se sustenta CD4ML incluye herramientas para el acceso y el descubrimiento de datos, control de versiones de artefactos (como los datos, el modelo y el código), pipelines de entrega continua, aprovisionamiento automatizado de entornos para distintas entregas y experimentos, evaluación y seguimiento del rendimiento del modelo y observabilidad operacional del modelo. Las compañías pueden elegir su propio conjunto de herramientas dependiendo de su stack tecnológico actual. CD4ML se focaliza en la automatización y la eliminación de traspasos manuales. CD4ML es nuestro enfoque de facto para desarrollar modelos de ML

    Historia
  • En el último año, hemos visto un cambio de interés acerca del machine-learning y en redes neuronales profundas en particular. Hasta ahora, el desarrollo de herramientas y técnicas ha sido impulsado por por el entusiasmo acerca de las extraordinarias capacidades de estos modelos. Actualmente, sin embargo, hay una preocupación creciente de que estos modelos puedan causar daño accidentalmente. Por ejemplo, un modelo podría ser entrenado para, inadvertidamente, tomar decisiones de crédito rentables, simplemente excluyendo aspirantes desfavorecidos. Afortunadamente, estamos viendo un creciente interés en pruebas de sesgo ético que pueden ayudar a descubrir decisiones potencialmente dañinas. Herramientas como lime, AI Fairness 360 o What-If Tool pueden ayudar a descubrir imprecisiones que puedan resultar en grupos de baja representados en datos de entrenamiento, y herramientas de visualización como Google Facets o Facets Dive puede ser usada para descubrir subgrupos dentro de un cuerpo de datos de entrenamiento. Hemos usado lime (local interpretable model-agnostic explanations) adicionalmente a estas técnicas para poder entender las predicciones de cualquier clasificador de aprendizaje automático y que están haciendo estos clasificadores (o modelos).

    Historia
  • Vemos cada vez más y más herramientas, como Apollo Federation, que pueden agregar múltiples endpoints de GraphQL en un solo grafo. Sin embargo, alertamos contra el mal uso de GraphQL, especialmente cuando se transforma en un protocolo sevidor-a-servidor. Nuestra experiencia es usar solamente GraphQL para agregar recursos del lado del servidor. Cuando se usa este patrón, los microservicios continúan exponiendo APIs RESTful bien definidas mientras que, por detrás, los servicios agregados o el uso del patron BFF (Backend for Frontends) usan los controladores de GraphQL como la implementación para juntar recursos de otros servicios. La composición del grafo está dirigida por ejercicios de modelado del dominio para asegurar que el lenguaje ubicuo se limita a subgrafos solo donde es necesario (en el caso de un microservicio por “bounded context”). Esta técnica simplifica la implementación interna de agregar servicios o BFFs, mientras que fomenta el uso de un buen modelado de los servicios para evitar REST anémico.

    Historia
  • Desde su introducción en el Radar en 2016, hemos visto una adopción generalizada de micro frontends para interfaces de usuario web. Recientemente, hemos visto proyectos que amplían este estilo arquitectónico para incluir también micro frontends para aplicaciones móviles. Cuando la aplicación se vuelve lo suficientemente grande y compleja, se hace necesario distribuir el desarrollo entre múltiples equipos. Esto presenta el desafío de mantener la autonomía del equipo mientras se integra su trabajo en una sola aplicación. Aunque hemos visto equipos que escriben sus propios frameworks para habilitar este estilo de desarrollo, los frameworks de modularización existentes como Atlas y Beehive también pueden simplificar el problema de integrar el desarrollo de aplicaciones con múltiples eq

    Historia
  • La adopción de la nube y de DevOps, al tiempo que aumentan la productividad de los equipos, que ahora pueden moverse más rápido y con menos dependencias hacia los equipos de operaciones centralizados y a la infraestructura, también ha limitado a los equipos que no tienen la habilidad de autogestionar una aplicación completa y el juego de operaciones. Algunas organizaciones han abordado este desafío creando equipos de producto de ingeniería de plataforma. Estos equipos mantienen una plataforma interna que les permite a los equipos de entrega implementar y operar sistemas en menos tiempo y con herramientas más sencillas. El énfasis está en el autoservicio basado en APIs y en las herramientas de soporte, manteniendo a los equipos de entrega responsables de soportar lo que desplieguen en la plataforma. Las organizaciones que consideran establecer un equipo de plataforma de este tipo deben tener cuidado de no crear accidentalmente un equipo de DevOps separado, ni tampoco simplemente renombrar su estructura existente de alojamiento y operaciones a plataforma. Si te preguntas cuál es la mejor forma de configurar los equipos de plataforma, hemos estado usando los conceptos de topologías de equipo para dividir los equipos de plataforma de nuestros proyectos en equipos de habilitación, equipos centrales de "plataforma dentro de una plataforma" y equipos enfocados en iniciativas.

    Historia
  • Las políticas de seguridad son reglas y procedimientos que protegen a nuestros sistemas de amenazas e interrupciones. Por ejemplo, las políticas de control de acceso definen y resguardan quiénes pueden acceder a qué tipo de servicios y recursos, y bajo qué circunstancias; o las políticas de seguridad de redes pueden limitar dinámicamente la velocidad del tráfico a un servicio en particular. El complejo panorama tecnológico de hoy exige tratar las políticas de seguridad como código , es decir, definirlas y mantenerlas bajo control de versiones, validarlas, desplegarlas automáticamente y monitorear su desempeño. Herramientas tales como el Open Policy Agent o plataformas como Istio proveen mecanismos flexibles de definición y ejecución de políticas que apoyan la práctica de tratar las políticas de seguridad como código.

    Historia
  • Los ciclos de aprendizaje semi supervisados son un tipo de flujo de trabajo iterativo de aprendizaje automático (machine-learning) que aprovechan las relaciones existentes entre los datos sin etiquetar. Estas técnicas pueden mejorar los modelos mediante la combinación de conjuntos de datos etiquetados y no etiquetados de varias maneras. En otros casos, comparan modelos entrenados con diferentes subconjuntos de los datos. A diferencia del aprendizaje no supervisado donde una máquina infiere clases a partir de datos no etiquetados o del aprendizaje supervisado donde los datos de entrenamiento están completamente etiquetados, las técnicas de aprendizaje semi supervisado toman ventaja de un pequeño conjunto de datos etiquetados y un conjunto mucho más grande de datos no etiquetados. Además, el aprendizaje semi supervisado está estrechamente relacionado con técnicas de aprendizaje activas, donde un humano es dirigido a etiquetar selectivamente datos ambiguos. Ya que los humanos expertos que puedan etiquetar datos con exactitud son un recurso escaso, y que etiquetar los datos es usualmente la tarea que requiere más tiempo en el flujo de trabajo del aprendizaje automático, las técnicas de aprendizaje semi supervisado reducen el coste del entrenamiento y hacen el aprendizaje automático viable para una nueva clase de usuarios. También observamos la aplicación de técnicas de aprendizaje débilmente supervisadas donde datos etiquetados por una máquina son usados, pero se confía menos en ellos que los datos etiquetados por un humano.

    Historia
  • Anteriormente habíamos puesto esta técnica en Evaluar. Las innovaciones en el panorama de la PNL continúan a un ritmo acelerado y podemos aprovecharlas en nuestros proyectos gracias a la ubicua transferencia de aprendizaje para PNL. Se ha visto un progreso significativo en los puntajes de referencia de GLUE (un conjunto de tareas de comprensión del lenguaje) durante los últimos años, con puntajes promedio que pasaban de 70.0 en un inicio y sobrepasando los 90.0 en abril de 2020 para algunos de los líderes. Muchos de nuestros proyectos en los dominios de PNL pueden lograr un progreso significativo si empiezan con modelos preentrenados de ELMo, BERT y ERNIE, entre otros, y luego afinarlos en función de las necesidades del proyecto.

    Historia
  • Los equipos distribuidos tienen varias formas y configuraciones mientras que los equipos de entrega ubicados al 100% en un entorno y ubicación conjunta, se han convertido en la excepción. La mayoría de nuestros equipos están en varias ubicaciones o tienen al menos algunos miembros trabajando remotamente. Por lo tanto, utilizar procesos y enfoques "nativos remotos" por defecto puede ayudar significativamente en la eficiencia y en el flujo general del equipo. El primer paso es asegurarse de que todas las personas tengan acceso remoto a los sistemas necesarios. Además, el uso de herramientas como Visual Studio Live Share, MURAL o Jamboard convierten los talleres virtuales y el trabajo remoto en pares en rutinas en lugar de ineficaces excepciones. Pero el ser “nativo remoto” va más allá del traslado de prácticas de entornos presenciales al mundo digital: hay que aceptar una comunicación más asíncrona, tener una mayor disciplina alrededor de la documentación de decisiones, e incluso tener reuniones donde “todas las personas están en remoto”. Estos enfoques, que nuestros equipos practican por defecto, sirven para optimizar y permitir fluidez en la ubicación.

    Historia
  • La realidad tecnológica actual es bastante más compleja para las organizaciones con activos (datos, funciones, infraestructura y usuarios) repartidos a través de varios límites de seguridad como servidores locales, múltiples proveedores de nube y una variedad de servicios SaaS. Esto requiere un cambio de paradigma en la planificación de seguridad a nivel empresarial y arquitectura de sistemas, pasando de un manejo estático de las políticas de seguridad, basadas en zonas de confianza y configuraciones de red, a la aplicación dinámica de políticas de seguridad detalladas basadas en privilegios de acceso temporal.

    La Arquitectura de Confianza Cero (zero trust architecture, ZTA) es una estrategia y un proceso de una organización para implementar principios de seguridad de confianza cero para todos sus activos, como dispositivos, infraestructura, servicios, datos y usuarios, ya que esto incluye la implementación de prácticas como asegurar todo tipo de acceso y comunicación sin importar el lugar de la red, aplicando políticas como código basadas en el menor privilegio y con la mayor granularidad posible, y el monitoreo continuo y la mitigación automatizada de amenazas. Nuestro Radar refleja muchas de las técnicas habilitadoras, tales como politicas de seguridad como código, sidecars para seguridad de endpoints, y BeyondCorp. Si estás en el proceso de la implementación de ZTA, revisa la publicación del NIST sobre ZTA para aprender más sobre principios, componentes de tecnologias habilitadoras y patrones de migración así como las publicaciones de Google sobre BeyondProd.

    Historia

Evaluar?

  • La malla de datos (data mesh) es un paradigma de arquitectura y de organización que desafía la vieja presunción de que se debe centralizar los grandes datos analíticos para utilizarlos, tener todos los datos en un mismo lugar o gestionarlos a través de un equipo de datos centralizado para entregar valor. Este paradigma afirma que, para que big data promueva la innovación, su propiedad debe ser federada entre los dueños de los datos de dominio quienes son responsables de proveer sus datos como productos (con el soporte de una plataforma de datos de autoservicio para abstraer la complejidad técnica que supone servir productos de datos); también se debe adoptar una nueva forma de gobierno federado a través de la automatización que permita la interoperabilidad de los productos de datos orientados a dominios. La descentralización, junto con la interoperabilidad y el enfoque en la experiencia para los consumidores de datos, son clave para la democratización de la innovación usando datos.

    Si en la organización existe un gran número de dominios con varios sistemas y equipos generando datos o un conjunto diverso de casos de uso y patrones de acceso basados en datos, sugerimos evaluar a malla de datos. La implementación de este paradigma requiere invertir en la construcción de una plataforma de datos de autoservicio y aceptar y promover un cambio organizacional para que los dominios tomen la propiedad a largo plazo de sus productos de datos, así como una estructura de incentivos que premien a los dominios que sirvan y utilicen datos como producto.

    Historia
  • Desde el nacimiento de la internet, el panorama tecnológico ha experimentado una evolución acelerada hacia la descentralización. Mientras los protocolos como HTTP y los patrones de arquitectura como microservicios o mallas de datos permiten realizar implementaciones descentralizadas, la gestión de la identidad continúa centralizada. Sin embargo, la aparición de tecnologías de libros de transacciones distribuidas (digital ledger technologies, DLT), brinda fundamentos al concepto de identidad descentralizada. En un sistema de este tipo, las entidades (unidades discretas identificables, como personas, organizaciones y cosas) son libres de usar cualquier raíz compartida de confianza. En contraste, los sistemas convencionales de gestión de la identidad se basan en autoridades y registros centrales como los servicios de directorio corporativo, autoridades de certificación o registros de nombres de dominio.

    El desarrollo de identificadores descentralizados (que son únicos globalmente, persistentes y son identificadores auto-soberanos verificables criptográficamente) es un estándar habilitador mayor. A pesar que todavía son pocas las implementaciones a escala de identificadores descentralizados, nos emociona la premisa de este movimiento y hemos empezado a usar el concepto en nuestra arquitectura. Para conocer los más recientes experimentos y colaboraciones de la industria, accede a la Decentralized Identity Foundation

    Historia
  • Muchos pipelines de datos se definen usando secuencias de comandos largas, en forma de código, más o menos, imperativo, escritas en Python o Scala. Estos códigos contienen tanto la lógica de los pasos individuales como la lógica que enlaza los pasos entre sí. Cuando los desarrolladores se enfrentaron a una situación similar con las pruebas de Selenium, descubrieron el patrón “Page Object”, y posteriormente muchos frameworks dirigidos por comportamiento, BDD por sus siglas en inglés, implementaron una división entre definición de los pasos y su composición. Algunos equipos están experimentando con la aplicación del mismo enfoque en ingeniería de datos. Una definición declarativa de pipeline de datos separada, tal vez escrita en YAML, contiene únicamente la declaración y la secuencia de pasos. Declara los tipos de datos de entrada y salida pero puede ejecutar comandos imperativos en otros archivos cuando se necesita una lógica más compleja. Con A La Mode, vemos a la primera herramienta de código abierto que aparece en este espacio.

    Historia
  • DeepWalk es un algoritmo que ayuda a aplicar aprendizaje automático en grafos. Al trabajar sobre conjuntos de datos representados como grafos, uno de los problemas principales es extraer características del grafo. Aquí es donde DeepWalk puede ayudar. Usa SkipGram para construir incrustaciones de nodos al ver el grafo como un lenguaje donde cada nodo es una palabra única en el lenguaje y caminos aleatorios de longitud finita sobre el grafo constituyen una oración. Estas incrustaciones pueden entonces ser usadas en varios modelos de aprendizaje automático. DeepWalk es una de las técnicas que estamos probando en algunos de nuestros proyectos donde hemos necesitado aplicar aprendizaje automático en grafos.

    Historia
  • Recomendamos precaución con la gestión de sistemas con estado mediante la orquestación de contenedores en plataformas como Kubernetes. Algunas bases de datos no han sido construidas con soporte nativo para la orquestación (no esperan que un planificador termine el proceso y las reubique en una máquina distinta). La construcción de un servicio con alta disponibilidad sobre estas bases de datos no es sencilla y aún recomendamos ejecutarlas en máquinas dedicadas (bare metal hosts) o una máquina virtual en lugar de obligarlas a ejecutarlas de manera forzada en una plataforma de orquestación de contenedores.

    Historia
  • Aunque abogamos fervientemente por la integración continua en lugar de Gitflow, sabemos que subir cambios (commit) directamente al trunk y ejecutar los procesos de integración continua en una rama master puede ser ineficiente si el equipo es demasiado grande, si la construcción es lenta o inconsistente, o si el equipo carece de la disciplina para ejecutar el conjunto completo de pruebas localmente. En esta situación, una compilación fallida puede bloquear a múltiples personas o pares de desarrollo. En lugar de corregir la causa subyacente del problema (compilaciones lentas, incapacidad de ejecutar pruebas localmente o arquitecturas monolíticas que requieren que muchas personas trabajen en la misma área), los equipos generalmente confían en las ramas por funcionalidades (feature branch) para esquivar estos problemas. Desaconsejamos este tipo de ramas, ya que pueden requerir un esfuerzo significativo para resolver conflictos al integrar cambios e introducen ciclos de retroalimentación más largos y posibles errores durante la resolución de conflictos. En su lugar, proponemos utilizar compilaciones preliminares como alternativa: son compilaciones basadas en peticiones de cambios (pull requests) para “micro ramas” que existen sólo durante la ejecución del pipeline de compilación y que se abren con cada commit. Para ayudar a automatizar este flujo de trabajo, nos hemos encontrado con bots como Bors que automatizan la integración de cambios con master y la eliminación de la micro rama en caso de que su compilación tenga éxito. Estamos considerando este flujo, y también deberías hacerlo; pero no para resolver el problema incorrecto, ya que puede llevar al mal uso de las ramas y puede causar más daño que beneficio.

    Historia

Resistir?

  • Es algo curioso, que luego de una década de experiencia de la industria con migraciones a la nube, que siga siendo necesario manifestarse frente a la idea de simplemente trasladarse (lift-and-shift) a la nube; donde la nube es vista simplemente como una solución de alojamiento, y la arquitectura existente, las prácticas de seguridad, los modelos de tecnología son simplemente replicados en la nube. Esto no cumple con las promesas de agilismo e innovación digital. Una verdadera migración a la nube requiere cambios intencionales en múltiples ejes para alcanzar un estado nativo de la nube, y dependiendo de circunstancias específicas de los procesos de migración, cada organización puede terminar en algún lugar en el espectro entre “traslado a la nube” y “nativo en la nube”. La arquitectura de sistemas, por ejemplo, es uno de los pilares de la entrega ágil y a menudo requiere ser cambiada. La tentación de simplemente trasladar sistemas existentes a contenedores puede ser muy fuerte. Aún cuando esta estrategia puede acelerar la migración a la nube, se queda corta cuando se trata de crear agilismo y entregar funcionalidades y valor. La seguridad empresarial en la nube es fundamentalmente diferente a la tradicional (seguridad basada en perímetros, típicamente compuesta de zonas y cortafuegos) y exige una transición hacía arquitecturas de cero confianza. Los modelos operacionales de tecnología tienen que ser renovados para proveer con seguridad servicios en la nube a través de plataformas de autoservicio automatizadas y empoderar a los equipos a tomar más de las responsabilidades operacionales y ganar autonomía. Y último, pero no menos importante, las organizaciones deben construir las bases para habilitar cambios continuos, tales como pipelines con pruebas continuas a las aplicaciones e infraestructuras como parte de la migración. Esto ayudará al proceso y tendrá como resultado un sistema más robusto y mejor estructurado, y dará a las organizaciones una forma para continuar evolucionando y mejorando sus sistemas.

    Historia
  • Hemos descubierto que cada vez más y más organizaciones tienen la necesidad de reemplazar sistemas heredados, para satisfacer las demandas de sus clientes (tanto internos como externos). Un antipatrón que continuamos viendo es la paridad de funcionalidades en migraciones de sistemas heredados , el deseo de retener una paridad de funcionalidad con lo antiguo. Consideramos que esto es una enorme oportunidad perdida. A menudo, los sistemas antiguos se han sobrecargado con el paso del tiempo, con muchas funcionalidades que los usuarios no utilizan (el 50% de acuerdo al reporte de 2014 de Standish Group) y procesos de negocio que han evolucionado con el tiempo. Reemplazar estas funcionalidades es perder el tiempo. Nuestro consejo: convence a tus clientes a dar un paso atrás y entender lo que sus usuarios necesitan actualmente, para luego priorizar estas necesidades en base a resultados comerciales y métricas — esto usualmente es más fácil de decir que de hacer. Esto significa que se debe conducir una investigación de necesidades del usuario y aplicar prácticas modernas de desarrollo de producto en lugar de simplemente reemplazar las existentes.

    Historia
  • Hace varios años, surgió una nueva generación de plataformas de agregación de registros (logs) que eran capaces de almacenar y buscar en grandes cantidades de datos de registros para descubrir tendencias y conocimientos sobre datos operativos. Splunk fue el más destacado pero de ninguna manera el único ejemplo de estas herramientas. Debido a que estas plataformas proporcionan una amplia visibilidad operativa y de seguridad en todo el conjunto de aplicaciones, los administradores y desarrolladores se han vuelto cada vez más dependientes de ellas. Este entusiasmo se extendió cuando las partes interesadas descubrieron que podían usar la agregación de registros (logs) para análisis de negocios. Sin embargo, las necesidades comerciales pueden superar rápidamente la flexibilidad y la facilidad de uso de estas herramientas. Los registros destinados a la observación técnica a menudo son inadecuados para inferir una comprensión profunda del cliente. Preferimos usar herramientas y métricas diseñadas específicamente para el análisis de los clientes o adoptar un enfoque de observabilidad más orientado a eventos, donde los eventos comerciales y operativos se recopilan y almacenan de manera que puedan reproducirse y procesarse con herramientas especialmente diseñadas para ese propósito.

    Historia
  • Hace cinco años ya resaltamos los problemas de las ramas de larga duración con Gitflow. En esencia, este tipo de ramas son lo contrario a integrar de forma continua todos los cambios del código fuente y, en nuestra experiencia, la integración contínua es el mejor enfoque para la mayoría de los proyectos de desarrollo de software. Un tiempo después, extendimos nuestra advertencia al mismo Gitflow porque observamos que algunos equipos lo usaban exclusivamente con ramas de larga duración. Hoy en día, aún hay equipos en entornos donde se tiene como objetivo hacer entrega continua de sistemas para la web, que se ven forzados a usar ramas de larga duración. Por ello, saludamos que el autor de Gitflow haya añadido una nota a su artículo original, explicando que Gitflow no estaba pensado para dicho uso.

    Historia
  • El valor de las pruebas basadas en capturas de pantalla es innegable cuando se trabaja con sistemas heredados ya que asegura que el sistema continúa funcionando y que el código heredado no falla. Sin embargo, hemos observado que es común usar como mecanismo principal de pruebas la perjudicial práctica de probar solamente con capturas de pantalla. Este tipo de pruebas validan la salida exacta generada en el DOM por un componente, no su comportamiento. Es por ello que pueden ser frágiles y poco fiables, fomentando la mala práctica de “eliminar la captura y volverla a generar”. En vez de eso, se debería probar la lógica y el comportamiento de los componentes emulando lo que harían los usuarios. Esta mentalidad es la recomendada por herramientas de la familia Testing Library.

    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