Master

Ferramentas

Adote?

  • Sentry tornou-se a escolha padrão para muitos de nossos times no que se refere a relatórios de erros de front-end. A conveniência de recursos como agrupamento de erros ou definição de padrões para descartar erros com determinados parâmetros ajuda a lidar com a enxurrada de erros provenientes de muitos dispositivos de usuários finais. Integrar o Sentry em seu pipeline de CD permite a você carregar mapas de origem para uma depuração de erros mais eficiente, e ajuda a rastrear facilmente quais erros ocorreram em qual versão do software. Também apreciamos o fato de que, embora o Sentry seja primordialmente uma oferta de SaaS, seu código-fonte está disponível para o público e pode ser usado gratuitamente para casos de uso menores e auto-hospedagem.

    Histórico

Experimente?

  • Tornar a web inclusiva requer muita atenção para garantir que a acessibilidade seja considerada e validada em todos os estágios da entrega de software. Muitas das ferramentas de teste de acessibilidade populares são projetadas para executar testes após a finalização de uma aplicação web. Como resultado, os problemas são detectados tardiamente e geralmente são mais difíceis de corrigir, acumulando-se como dívidas. Em nosso trabalho interno recente nos sites da Thoughtworks, incluímos o mecanismo de teste de acessibilidade (a11y) de código aberto axe-core como parte de nossos processos. Ele forneceu aos membros do time um feedback inicial sobre a adesão às regras de acessibilidade, mesmo durante os primeiros incrementos. No entanto, nem todos os problemas podem ser encontrados por meio da inspeção automatizada. Para estender a funcionalidade do axe-core, temos o axe DevTools disponível comercialmente, incluindo uma funcionalidade que orienta os membros do time por meio de testes exploratórios para a maioria dos problemas de acessibilidade.

    Histórico
  • Desde a última vez que escrevemos sobre dbt, nós temos usado em alguns projetos e gostamos do que vimos. Por exemplo, gostamos do fato de que o dbt torna a parte da transformação de pipelines ELT mais acessível para consumidores de dados, em contraste com a prática de apenas pessoas engenheiras de dados construindo pipelines. O dbt faz isso ao mesmo tempo em que incentiva boas práticas de engenharia, como controle de versão, implantação e testes automatizados. SQL continua a ser a língua franca do mundo dos dados (incluindo bancos de dados, warehouses, motores de consulta, lagos de dados e plataformas analíticas) e a maioria desses sistemas oferece suporte até certo ponto. Isso permite que o dbt seja usado nesses sistemas para transformações, apenas criando adaptadores. O número de conectores nativos cresceu para incluir Snowflake, BigQuery, Redshift e Postgres, assim como a variedade de plugins da comunidade. Vemos ferramentas como o dbt ajudando as plataformas de dados a ampliar sua capacidade de "autoatendimento".

    Histórico
  • Sempre procuramos encontrar ferramentas que sejam capazes de encurtar o ciclo de feedback do desenvolvimento de software. esbuild é um exemplo. Conforme a base de código do front-end cresce, geralmente enfrentamos um tempo de alguns minutos de empacotamento. Como um empacotador JavaScript otimizado para velocidade, o esbuild pode reduzir este tempo por um fator de 10 a 100. Ele é escrito em Golang e usa uma abordagem mais eficiente no processo de análise, impressão e geração de mapa de origem que supera significativamente as ferramentas de construção, como Webpack e Parcel em tempo de compilação. O esbuild pode não ser tão abrangente quanto essas ferramentas na transformação da sintaxe JavaScript. No entanto, isso não tem impedido que muitos de nossos times migrem para o esbuild como padrão.

    Histórico
  • Flipper é um depurador de aplicação móvel extensível. Ele oferece suporte para criação de perfis, inspeção de layout interativa, visualizador de log e um inspetor de rede para aplicações iOS, Android e React Native. Em comparação com outras ferramentas de depuração para aplicações móveis, achamos o Flipper leve, rico em recursos e fácil de configurar.

    Histórico
  • Escrevemos sobre Great Expectations na edição anterior do Radar. Continuamos gostando e o movemos para o anel Avalie nesta edição. Great Expectations é um framework que permite criar controles integrados que sinalizam anomalias ou problemas de qualidade em pipelines de dados. Assim como os testes de unidade são executados em um pipeline de compilação, o Great Expectations faz afirmações durante a execução de um pipeline de dados. Gostamos de sua simplicidade e facilidade de uso — as regras armazenadas em JSON podem ser modificadas por especialistas em domínio de dados sem necessariamente precisar de habilidades de engenharia de dados.

    Histórico
  • Tivemos um pouco mais de experiências em testes de desempenho com k6 desde que o incluímos pela primeira vez no Radar, e com bons resultados. Nossos times têm gostado do foco na experiência de desenvolvimento e na flexibilidade da ferramenta. Embora seja fácil de começar a usar o k6 sozinho, ele realmente se destaca por sua facilidade de integração em um ecossistema de desenvolvimento. Por exemplo, usando o adaptador Datadog, um time foi capaz de visualizar rapidamente o desempenho em um sistema distribuído, identificando preocupações significativas antes de liberar o sistema em produção. Outro time, com a versão comercial do k6, conseguiu usar a extensão do Azure pipelines marketplace para fazer testes de desempenho em seu pipeline de CD e obter relatórios do Azure DevOps com pouco esforço. Como o k6 oferece suporte a limites que permitem asserções de teste automatizadas prontos para uso, é relativamente fácil adicionar um estágio ao pipeline para detectar a degradação do desempenho de novas mudanças, adicionando um poderoso mecanismo de feedback para pessoas desenvolvedoras.

    Histórico
  • MLflow é uma ferramenta de código aberto para rastreamento de experimentos de aprendizado de máquina e gerenciamento de ciclo de vida. O fluxo de trabalho para desenvolver e evoluir continuamente um modelo de aprendizado de máquina inclui uma série de experimentos (uma coleção de execuções), rastreamento de desempenho desses experimentos (uma coleção de métricas) e rastreamento e ajuste de modelos (projetos). O MLflow facilita esse fluxo de trabalho muito bem, suportando os padrões abertos existentes e se integrando bem com muitas outras ferramentas no ecossistema. O MLflow como um serviço gerenciado por Databricks na nuvem, disponível em AWS e Azure, está amadurecendo rapidamente e temos usado com sucesso em nossos projetos. Consideramos o MLflow uma ótima ferramenta para gerenciamento e rastreamento de modelos, com suporte para modelos de interação baseados em UI e API. Nossa única e crescente preocupação é que o MLflow tenta entregar muitas questões conflitantes como uma única plataforma, por exemplo, modelos de serviço e pontuação.

    Histórico
  • OR-Tools é um conjunto de softwares de código aberto para resolver problemas de otimização combinatória. Os problemas de otimização têm um conjunto muito grande de soluções possíveis, e ferramentas como OR-Tools são bastante úteis na busca da melhor solução. Você pode modelar o problema em qualquer uma das linguagens suportadas — Python, Java, C# ou C++ — e escolher entre vários solvers de código aberto ou comerciais suportados. Usamos com sucesso o OR-Tools em vários projetos de otimização com programação inteira e inteira mista.

    Histórico
  • Playwright permite escrever testes de Web UI para Chromium, Firefox, e também para WebKit, tudo por meio da mesma API. A ferramenta ganhou alguma atenção por seu suporte a todos os principais motores de busca de navegadores, algo que ela consegue fazer ao incluir versões corrigidas do Firefox e do Webkit. Continuamos ouvindo relatos de experiências positivas com Playwright, em particular sobre sua estabilidade. Os times também acharam simples migrar do Puppeteer, que tem uma API muito semelhante.

    Histórico
  • Celebramos o aumento da disponibilidade e a maturidade das ferramentas de análise de configuração de infraestrutura: Prowler ajuda os times a analisar suas configurações de infraestrutura da AWS e melhorar a segurança com base nos resultados. Embora o Prowler já exista há algum tempo, a ferramenta evoluiu muito nos últimos anos e achamos muito valiosa sua capacidade de habilitar os times a assumir a responsabilidade pela segurança com um curto ciclo de feedback. Prowler categoriza as análises do benchmarking AWS CIS em diferentes grupos (gerenciamento de identidade e acesso, registro, monitoramento, rede, nível CIS 1, nível CIS 2, EKS-CIS), e inclui muitas análises que ajudam a obter informações sobre conformidade com PCI DSS e GDPR.

    Histórico
  • Embora duck typing seja certamente visto como um recurso interessante por muitas pessoas que programam em Python, às vezes — especialmente para bases de código maiores — a verificação de tipo também pode ser útil. Por esse motivo, várias anotações de tipo são propostas como Python Enhancement Proposals (PEPs) e Pyright é um verificador de tipos que funciona com essas anotações. Além disso, ele fornece inferências de tipo e algumas proteções que entendem construções de fluxo de código condicional. Projetado para grandes bases de código, o Pyright é rápido e suas verificações de modo de observação acontecem de forma incremental conforme os arquivos são alterados para encurtar ainda mais o ciclo de feedback. O Pyright pode ser usado diretamente na linha de comando, mas integrações para VS Code, Emacs, vim, Sublime e possivelmente outros editores também estão disponíveis. Em nossa experiência, o Pyright é preferível em relação a alternativas como mypy.

    Histórico
  • A adoção de uma filosofia DevOps do tipo "você constrói, você executa" significa que os times devem ter maior atenção às métricas técnicas e de negócios que podem ser extraídas dos sistemas que são implantados. Frequentemente, descobrimos que as ferramentas analíticas são de difícil acesso para a maioria das pessoas desenvolvedoras e, portanto, o trabalho de capturar e apresentar as métricas é deixado para outros times — bem depois que as funcionalidades são enviadas às pessoas usuárias finais. Nossos times consideram o Redash muito útil para consultar métricas de produtos e criar dashboards que possam ser usados por pessoas desenvolvedoras em geral, reduzindo os ciclos de feedback e concentrando todo o time nos resultados do negócio.

    Histórico
  • O Terratest chamou nossa atenção no passado como uma opção interessante para testes de infraestrutura. Desde então, nossos times o têm usado e estão bastante entusiasmados com a estabilidade e a experiência oferecida. Terratest é uma biblioteca Golang que torna mais fácil escrever testes automatizados para código de infraestrutura. Usando ferramentas de infraestrutura como código, como Terraform, você pode criar componentes de infraestrutura reais (como servidores, firewalls ou balanceadores de carga) para implantar aplicações neles e validar o comportamento esperado usando Terratest. Ao final do teste, o Terratest pode “desimplantar” as aplicações e limpar os recursos. Isso o torna muito útil para testes de ponta a ponta de sua infraestrutura em um ambiente real.

    Histórico
  • Tuple é uma ferramenta relativamente nova otimizada para programação em pares remota, projetada para preencher a lacuna que o Slack deixou no mercado após abandonar o Screenhero. Embora ainda exiba alguns problemas crescentes — a disponibilidade da plataforma está limitada ao Mac OS por enquanto (com suporte para Linux em breve) e existem algumas peculiaridades de UI a serem resolvidas — tivemos uma boa experiência de uso considerando essas restrições. Ao contrário de ferramentas de compartilhamento de vídeo e tela de uso geral, como o Zoom, o Tuple oferece suporte a controle duplo com dois cursores de mouse, e ao contrário de opções como o Visual Studio Live Share, não está vinculado a um IDE. Tuple oferece suporte a chamadas de voz e vídeo, compartilhamento de área de transferência e menor latência do que ferramentas de uso geral, e o recurso que permite desenhar e apagar na tela de seu par com facilidade torna o Tuple uma ferramenta muito intuitiva e amigável para pessoas desenvolvedoras.

    Histórico
  • Ao trabalhar com React, muitas vezes encontramos situações em que nossa página fica muito lenta porque alguns componentes são renderizados novamente quando não deveriam ser. Why Did You Render é uma biblioteca que ajuda a detectar por que um componente está sendo renderizado novamente. Ela faz isso aplicando um monkey patch no React. Nós a usamos em alguns de nossos projetos para depurar problemas de desempenho com grandes resultados.

    Histórico

Avalie?

  • Embora o Docker tenha se tornado o padrão sensato para a conteinerização, temos visto novos players neste espaço que estão chamando nossa atenção. É o caso de Buildah e Podman, que são projetos complementares para construção de imagens (Buildah) e execução de contêineres (Podman) usando uma abordagem sem usuário root em várias distribuições Linux. O Podman apresenta um mecanismo sem daemon para gerenciar e executar contêineres, que é uma abordagem interessante em comparação com o que o Docker faz. O fato de o Podman poder usar imagens Open Container Initiative (OCI) criadas pelo Buildah, ou imagens Docker, torna essa ferramenta ainda mais atraente e fácil de usar.

    Histórico
  • Ferramentas de compilação e servidores de CI estão entre as mais antigas e usadas ​​em nosso conjunto de ferramentas. Elas vão desde simples serviços hospedados em nuvem até servidores de pipeline complexos e definidos por código que oferecem suporte a frotas de máquinas de compilação. Dada a nossa experiência e a ampla gama de opções já disponíveis, adotamos inicialmente uma postura de ceticismo quando o GitHub Actions foi introduzido como mais um mecanismo para gerenciar o fluxo de compilação e integração. Mas a possibilidade de começar com um comportamento pequeno e facilmente personalizado para as pessoas desenvolvedoras significa que o GitHub Actions está se movendo em direção à categoria padrão de projetos menores. É difícil argumentar contra a conveniência de ter a ferramenta de compilação integrada diretamente no repositório do código-fonte. Uma comunidade entusiasmada surgiu em torno desse recurso e isso significa que uma ampla gama de ferramentas e fluxos de trabalho criados com a contribuição de pessoas usuárias está disponível. Fornecedores de ferramentas também têm demonstrado interesse via GitHub Marketplace. No entanto, ainda recomendamos que você proceda com cautela. Embora o código e o histórico do Git possam ser exportados para hosts alternativos, um fluxo de trabalho de desenvolvimento baseado no GitHub Actions não pode. Além disso, você deve usar seu bom senso para determinar quando um projeto é grande ou complexo o suficiente para justificar uma ferramenta de pipeline com suporte independente. Mas para começar a trabalhar rapidamente em projetos menores, vale a pena considerar o GitHub Actions e seu ecossistema em crescimento.

    Histórico
  • Graal Native Image é uma tecnologia que compila código Java em um binário nativo do sistema operacional — na forma de um executável estaticamente vinculado ou uma biblioteca compartilhada. Uma imagem nativa é otimizada para reduzir o consumo de memória e o tempo de inicialização de uma aplicação. Nossos times têm usado com sucesso imagens nativas do Graal, executadas como pequenos contêineres do Docker na arquitetura sem servidor, em que a redução do tempo de inicialização é importante. Embora projetada para uso com linguagens de programação como Go ou Rust, que compilam nativamente e exigem binários menores e tempos de inicialização mais curtos, a imagem nativa do Graal pode ser igualmente útil para times que têm outros requisitos e desejam usar linguagens baseadas em JVM.

    O Graal Native Image Builder, native-image, oferece suporte a linguagens baseadas em JVM — como Java, Scala, Clojure e Kotlin — e cria executáveis em vários sistemas operacionais como Mac OS, Windows e várias distribuições Linux. Uma vez que ele requer uma suposição de mundo fechado, na qual todo o código é conhecido no tempo de compilação, é necessária uma configuração adicional para recursos como reflection ou dynamic class loading, uma vez que os tipos não podem ser deduzidos apenas no tempo de compilação do código.

    Histórico
  • O HashiCorp Boundary reúne uma rede segura e os recursos de gerenciamento de identidade necessários para intermediar o acesso a seus hosts e serviços em um só lugar, combinando nuvem e recursos locais, se necessário. O gerenciamento de chaves pode ser feito integrando o serviço de sua escolha, seja de uma fornecedora de nuvem ou de algo como o HashiCorp Vault. O HashiCorp Boundary oferece suporte a um número crescente de provedores de identidade e pode ser integrado a partes de sua configuração de serviços para ajudar a definir permissões, não apenas no host, mas também em um nível de serviço. Por exemplo, ele permite que você controle as restrições de acesso a um cluster do Kubernetes, e a extração de catálogos de serviço de várias fontes está nos planos. Tudo isso fica fora do caminho das pessoas usuárias finais de engenharia, que obtêm a experiência de shell com a qual estão acostumadas, com uma conexão segura por meio da camada de gerenciamento de rede do Boundary.

    Histórico
  • Você se lembra do projeto de pesquisa pix2code, que mostrou como gerar código automaticamente a partir de capturas de tela da GUI? Agora, há uma versão desta técnica em formato de produto. imgcook é um produto SaaS da Alibaba que pode transformar de forma inteligente vários arquivos de design (Sketch/PSD/imagens estáticas) em código de front-end. A Alibaba precisa personalizar um grande número de páginas de campanha durante o festival de compras Double Eleven. Geralmente são páginas para uso específico nesse período que precisam ser desenvolvidas rapidamente. Por meio do método de aprendizado profundo, o design de UX é inicialmente processado em código de front-end e, em seguida, ajustado por uma pessoa desenvolvedora. Nosso time está avaliando esta tecnologia: embora o processamento de imagem ocorra no lado do servidor, enquanto a interface principal está na web, o imgcook fornece ferramentas que podem se integrar com o design de software e o ciclo de vida do desenvolvimento. O imgcook pode gerar código estático, bem como algum código de componente de vinculação de dados, caso você defina uma DSL. A tecnologia ainda não é perfeita: designers precisam consultar certas especificações para melhorar a precisão da geração de código (que ainda precisa ser ajustada por pessoas desenvolvedoras posteriormente). Sempre temos cautela com a geração de código mágica, porque o código gerado costuma ser difícil de manter a longo prazo, e o imgcook não é exceção. Mas se você limitar o uso a um contexto específico, como páginas para campanhas específicas, vale a pena tentar.

    Histórico
  • Longhorn é um sistema de armazenamento de bloco distribuído para Kubernetes. Existem muitas opções de armazenamento persistente para Kubernetes. Ao contrário da maioria, no entanto, o Longhorn é construído desde o início para fornecer backups e snapshots incrementais, facilitando assim a execução de um armazenamento replicado para Kubernetes não hospedado em nuvem. Com o recente suporte experimental para ReadWriteMany (RWX), você pode até montar o mesmo volume para acesso de leitura e gravação em vários nós. Escolher o sistema de armazenamento certo para Kubernetes não é uma tarefa trivial, e recomendamos que você avalie o Longhorn com base em suas necessidades.

    Histórico
  • Operator Framework é um conjunto de ferramentas de código aberto que simplifica a construção e o gerenciamento do ciclo de vida dos operadores Kubernetes. O padrão de operador do Kubernetes, originalmente introduzido pelo CoreOS, é uma abordagem para encapsular o conhecimento de operação de uma aplicação usando recursos nativos do Kubernetes. Inclui recursos a serem gerenciados e código do controlador , garantindo que os recursos correspondam ao estado de desejado. Essa abordagem foi usada para estender o uso do Kubernetes ao gerenciamento de várias aplicações, especialmente aquelas com estado, nativamente. O Operator Framework tem três componentes: Operator SDK, que simplifica a construção, os testes e o empacotamento de operadores Kubernetes; o Gerenciador de ciclo de vida, para instalar, gerenciar e atualizar os operadores; e um catálogo, para publicar e compartilhar operadores de terceiras partes. Nossos times consideram o Operator SDK particularmente poderoso no desenvolvimento rápido de aplicações nativas do Kubernetes.

    Histórico
  • O número de serviços oferecidos pelas grandes provedoras de nuvem continua crescendo, mas a conveniência e a maturidade das ferramentas que ajudam a usar esses serviços com segurança e eficiência também vem crescendo. O Recomendador é um serviço da Google Cloud que analisa seus recursos e fornece recomendações sobre como otimizá-los com base em seu uso real. O serviço consiste em uma variedade de "recomendadores" em áreas como segurança, uso de computação ou economia de custos. O Recomendador do IAM, por exemplo, ajuda a implementar melhor o princípio do menor privilégio, apontando permissões que nunca são de fato usadas e, portanto, são potencialmente amplas demais.

    Histórico
  • Nos últimos anos, o Subsistema Windows para Linux (WSL) surgiu algumas vezes em nossas discussões. Apesar de gostarmos do que vimos, incluindo as melhorias no WSL 2, ele nunca foi incluído no Radar. Nesta edição, queremos destacar uma extensão para Visual Studio Code que melhora muito a experiência de trabalho com o WSL. Ainda que os editores baseados em Windows sempre pudessem acessar os arquivos em um sistema de arquivos WSL, eles desconheciam o ambiente Linux isolado. Com a extensão Remote - WSL, o Visual Studio Code torna-se ciente do WSL, permitindo às pessoas desenvolvedoras iniciar um shell do Linux. Isso também permite a depuração de binários em execução no WSL do Windows. O IntelliJ da Jetbrains também tem recebido melhorias constantes em seu suporte para WSL.

    Histórico
  • Um padrão que vimos se repetir nesta publicação é que ferramentas estáticas de verificação de erros e estilo surgem rapidamente após uma nova linguagem ganhar popularidade. Essas ferramentas são genericamente conhecidas como linters — em homenagem ao clássico e amado utilitário do Unix, lint, que analisa estaticamente código em C. Gostamos dessas ferramentas porque elas detectam os erros cedo, antes mesmo que o código seja compilado. A instância mais recente desse padrão é Spectral, um linter para YAML e JSON. Embora Spectral seja uma ferramenta genérica para esses formatos, seus alvos principais são OpenAPI (a evolução do Swagger) e AsyncAPI. O Spectral vem com um conjunto abrangente de regras prontas para usar para especificações que podem evitar dores de cabeça para pessoas desenvolvedoras ao projetar e implementar APIs ou colaboração orientada a eventos. Essas regras verificam as especificações adequadas aos parâmetros da API ou a existência de uma declaração de licença na especificação, entre outras coisas. Embora essa ferramenta seja uma adição bem-vinda ao fluxo de desenvolvimento de APIs, ela levanta a questão: uma especificação não executável deve ser tão complexa a ponto de exigir uma técnica de verificação de erros projetada para linguagens de programação? Talvez as pessoas desenvolvedoras devam se concentrar em escrever código, e não especificações.

    Histórico
  • Yelp detect-secrets é um módulo Python para detectar segredos em uma base de código, fazendo a verificação de arquivos em um diretório em busca de segredos. Ele pode ser usado como um hook de pré-commit do Git ou para executar uma verificação em vários locais dentro do pipeline de CI/CD. Ele vem com uma configuração padrão que o torna muito fácil de usar, mas pode ser modificado para atender às suas necessidades. Você também pode instalar plugins personalizados para adicionar às pesquisas heurísticas padrão. Em comparação com ofertas semelhantes, consideramos que essa ferramenta detecta mais tipos de segredos com sua configuração padrão.

    Histórico
  • Conforme o ecossistema de especificações de API amadurece, temos visto mais ferramentas construídas para automatizar as verificações de estilo. Zally é um linter OpenAPI minimalista que ajuda a garantir que uma API esteja em conformidade com o guia de estilo de API do time. Pronto para uso, ele valida em relação a um conjunto de regras desenvolvido para o guia de estilo de API da Zalando, mas também suporta um mecanismo de extensão do Kotlin para desenvolver regras personalizadas. O Zally inclui uma UI da web que fornece uma interface intuitiva para entender as violações de estilo e uma CLI que facilita a conexão ao pipeline de CD.

    Histórico

Evite?

  • Com base nas experiências de vários times da Thoughtworks, sugerimos abordar AWS CodePipeline com cautela. Especificamente, descobrimos que, uma vez que os times vão além de pipelines simples, essa ferramenta pode se tornar difícil de trabalhar. Embora possa parecer um "sucesso rápido" ao começar trabalhar com AWS, sugerimos dar um passo atrás e verificar se o AWS CodePipeline atende às suas necessidades de longo prazo, por exemplo, pipeline fan-out e fan-in ou implementações mais complexas e cenários de teste com dependências e gatilhos não triviais.

    Histórico
Não encontrou algo que você esperava achar?

Cada edição do Radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um Radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode estar faltando um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

Novo,Modificado,Sem alteração