Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Técnicas

Adote ?

  • Para medir o desempenho da entrega de software, cada vez mais organizações vêm adotando as quatro métricas fundamentais, definidas pelo programa DORA research: lead time, frequência de implantação, tempo médio de restauração (MTTR) e porcentagem de falha de alteração. A pesquisa e sua análise estatística mostram uma ligação nítida entre alta performance de entrega e essas métricas, que fornecem um ótimo indicador de desempenho para um time, ou até mesmo uma organização inteira.

    Ainda defendemos fortemente o uso dessas métricas, mas aprendemos algumas lições. Ainda temos observado o uso cada vez mais frequente de abordagens de medição equivocadas, com ferramentas que ajudam os times a obter essas métricas baseando-se somente em seus canais de entrega contínua (CD). Particularmente, quando se trata de métricas de estabilidade (MTTR e porcentagem de falha de alteração), os dados do pipeline de CD por si só não fornecem informações suficientes para determinar o que é uma falha de implantação com impacto real para os usuários. As métricas de estabilidade só fazem sentido se incluírem dados sobre incidentes reais que prejudicam a experiência de uso do serviço.

    Recomendamos sempre ter em mente a intenção final por trás de uma métrica, usando-a para refletir e aprender. Por exemplo, antes de passar semanas desenvolvendo ferramentas sofisticadas de dashboard, considere incluir a verificação rápida do DORA regularmente em retrospectivas do time. Isso dá ao time oportunidade de refletir sobre quais recursos podem ser trabalhados para melhorar suas métricas, o que pode ser muito mais efetivo do que usar ferramentas prontas para uso excessivamente detalhadas. Tenha em mente que essas quatro métricas principais se originaram de pesquisas de nível organizacional com times de alto desempenho, e o uso dessas métricas no nível do time deve ser uma maneira de refletir sobre os comportamentos do time, e não apenas mais um conjunto de métricas para adicionar ao dashboard.

  • Uma parede remota única para o time é uma técnica simples para reintroduzir a parede do time virtualmente. Recomendamos que os times distribuídos adotem essa abordagem. Uma das coisas que ouvimos de equipes que migraram para o trabalho remoto é que sentem falta de ter a parede física do time. Era um lugar único em que todos os vários cartões de histórias, tarefas, status e progresso podiam ser exibidos, funcionando como um radiador de informações e um hub para o time. A parede assumiu o papel de um ponto de integração, com os dados reais sendo armazenados em diferentes sistemas. À medida que os times se tornaram remotos, precisaram voltar a olhar para os sistemas de origem individuais, e obter uma visão rápida de um projeto tornou-se muito difícil. Embora possa haver alguma sobrecarga em mantê-la atualizada, sentimos que os benefícios para o time justificam. Para algumas equipes, a atualização da parede física fazia parte das "cerimônias" diárias que eram realizadas em conjunto, e o mesmo pode ser feito com uma parede remota.

Experimente ?

  • A malha de dados é uma abordagem organizacional e técnica descentralizada de compartilhamento, acesso e gerenciamento de dados para análise e ML. Seu objetivo é criar uma abordagem sociotécnica que expanda a obtenção de valor dos dados à medida que a complexidade da organização cresce e à medida que os casos de uso de dados se multiplicam e as fontes de dados se diversificam. Essencialmente, a abordagem cria um modelo de compartilhamento de dados responsável que acompanha o crescimento organizacional e mudança contínua. Em nossa experiência, o interesse na aplicação de malha de dados cresceu imensamente, inspirando muitas organizações a adotá-la e muitas fornecedoras de tecnologia a repensar suas ofertas existentes para incluir uma implantação de malha. Apesar do interesse e da experiência crescente em malha de dados, suas implementações enfrentam alto custo de integração. Além disso, sua adoção permanece limitada a determinadas partes de grandes organizações, e fornecedoras de tecnologia estão desviando a atenção das organizações em relação aos aspectos sociais inegociáveis da malha de dados – descentralização de dados e um modelo operacional de governança federada.

    Essas ideias são exploradas no livro Data Mesh, Delivering Data-Driven Value at Scale, que orienta profissionais de arquitetura, lideranças técnicas e responsáveis pela tomada de decisões em suas jornadas de transição da arquitetura tradicional de big data para a malha de dados. O material fornece uma introdução completa aos princípios da malha de dados e suas constituintes e aborda como projetar uma arquitetura de malha de dados, como orientar e executar uma estratégia de malha de dados e como navegar pelo design organizacional em um modelo de propriedade de dados descentralizado. O objetivo do livro é criar um novo framework para conversas mais profundas e levar a malha de dados ao próximo estágio de maturidade.

  • Em uma organização que pratica o princípio "você constrói, você executa", uma definição de prontidão para produção (DPR) é uma técnica útil para apoiar os times na avaliação e preparação da prontidão operacional de novos serviços. Implementada como uma lista de verificação ou um modelo, uma DPR orienta os times sobre o que considerar antes de colocar um novo serviço em produção. Embora DPRs não definam objetivos específicos no nível de serviço (service-level objectives ou SLOs) a serem cumpridos (esses seriam difíceis de definir como tamanho único), funcionam como lembretes de quais categorias de SLOs os times devem considerar, quais padrões organizacionais devem ser cumpridos e qual documentação é necessária. DPRs fornecem uma fonte de input que os times transformam em requisitos específicos de produtos para seus respectivos casos de uso, por exemplo, observabilidade e confiabilidade para alimentar seus backlogs de produto.

    As DPRs estão intimamente relacionadas ao conceito do Google de revisão de prontidão para produção (PRR). Em organizações muito pequenas para uma equipe dedicada de engenharia de confiabilidade de sites, ou em organizações que se preocupam com o impacto negativo que um processo de revisão por conselho pode ter no fluxo de lançamento de um time, ter uma DPR pode ao menos fornecer alguma orientação e documentar os critérios acordados para a organização. Para novos serviços altamente críticos, uma verificação extra no cumprimento do DPR pode ser adicionada por meio de uma PRR quando necessário.

  • Escrever uma boa documentação é um aspecto negligenciado do desenvolvimento de software, muitas vezes sendo deixado para o último minuto e executado de forma casual. Alguns de nossos times encontraram nos quadrantes de documentação uma maneira prática de garantir que os artefatos corretos estejam sendo produzidos. Essa técnica classifica os artefatos em dois eixos: o primeiro eixo diz respeito à natureza da informação — prática ou teórica; o segundo eixo descreve o contexto em que os artefatos são usados — estudo ou trabalho. Dessa forma, são definidos quatro quadrantes nos quais artefatos como tutoriais, guias de instruções ou páginas de referência podem ser colocados e compreendidos. Esse sistema de classificação não apenas garante que artefatos críticos não sejam esquecidos, mas também orienta a apresentação do conteúdo. Achamos essa técnica particularmente útil para criar documentação de onboarding e acelerar a integração de pessoas desenvolvedoras em um novo time.

  • O termo standup surgiu da ideia de ficar de pé durante essa reunião diária de sincronização, com o objetivo de torná-la curta. É um princípio comum que muitos times tentam seguir em suas standups: mantê-la objetiva e pragmática. Atualmente, no entanto, temos visto times desafiando esse princípio e repensando as standups remotas. Presencialmente, há muitas oportunidades no decorrer do dia para que as pessoas sincronizem umas com as outras de forma espontânea, de forma complementar à standup curta. Remotamente, alguns de nossos times estão experimentando um formato de reunião mais longo, semelhante ao que o pessoal da Honeycomb chama de “meandering team sync”.

    Não se trata de se livrar completamente de uma sincronização diária, ainda consideramos isso muito importante e valioso, especialmente em uma configuração remota. Em vez disso, trata-se de estender o tempo reservado nas agendas para a sincronização diária para até uma hora, e usá-lo de uma maneira que torne algumas das outras reuniões do time obsoletas e aproxime as pessoas do time. As atividades ainda podem incluir a já bastante testada revisão do quadro do time, mas sendo estendidas para discussões de esclarecimento mais detalhadas, decisões rápidas e tempo para socializar. A técnica pode ser considerada bem-sucedida se reduzir a carga geral da reunião e melhorar a conexão entre o time.

  • Quando criamos uma nova edição do Radar, muitas vezes experimentamos uma sensação de déjà vu. A técnica de UI orientada a servidor é um caso particularmente sólido, com o advento de frameworks que permitem que pessoas desenvolvedoras mobile se beneficiem de ciclos de mudança mais rápidos, sem infringir nenhuma das políticas da loja de aplicativos em relação à revalidação do aplicativo móvel em si. Já abordamos isso anteriormente sob a perspectiva de permitir que o desenvolvimento para dispositivos móveis seja escalado entre os times. A interface de usuário orientada a servidor separa a renderização em um contêiner genérico no aplicativo móvel, enquanto a estrutura e os dados de cada visualização são fornecidos pelo servidor. Isso significa que as alterações que antes exigiam uma viagem de ida e volta à loja de aplicativos agora podem ser realizadas por meio de alterações simples nas respostas que o servidor envia. Observe que não estamos recomendando essa abordagem para todo o desenvolvimento de UI. Na verdade, tivemos experiências com algumas bagunças terríveis e excessivamente configuráveis, mas, com o apoio de gigantes como AirBnB e Lyft, suspeitamos que não sejamos apenas nós da Thoughtworks que nos cansamos de tudo sendo feito do lado do cliente. Fique de olho nesse espaço.

  • Com a pressão contínua para manter os sistemas seguros e nenhum sinal de recuo no cenário geral de ameaças, uma lista de materiais de software (software bill of materials ou SBOM) legível por máquina pode ajudar os times a se manterem atualizados sobre os problemas de segurança em suas bibliotecas de confiança. A recente exploração remota de dia zero do Log4Shell foi crítica e teve amplo alcance; se os times tivessem uma SBOM pronta, poderiam ter verificado e corrigido rapidamente. Agora, temos experiências usando SBOMs em produção em projetos que vão de pequenas empresas a grandes multinacionais e até departamentos governamentais, e temos convicção de que as listas trazem benefícios. Ferramentas como Syft facilitam o uso de uma SBOM para detecção de vulnerabilidades.

  • Tactical forking é uma técnica que pode ajudar na reestruturação ou migração de bases de código monolíticas para microsserviços. Especificamente, essa técnica oferece uma alternativa possível para a abordagem mais comum, modularizar integralmente a base de código primeiro, o que em muitas circunstâncias pode levar muito tempo ou ser muito difícil de alcançar. Com a técnica de tactical forking, um time pode criar um novo fork da base de código e usá-lo para abordar e extrair uma preocupação ou área específica enquanto exclui o código desnecessário. O uso dessa técnica seria provavelmente apenas uma parte de um plano de longo prazo para o monólito de forma geral.

  • A arquitetura de um sistema imita a estrutura organizacional e sua comunicação. Não é exatamente novidade que devemos ser intencionais em relação a como os times interagem — veja, por exemplo, a Manobra Inversa de Conway. A interação do time é uma das variáveis que determinam a rapidez e a facilidade com as quais os times podem entregar valor a clientes. Ficamos felizes em encontrar uma maneira de medir essas interações. Usamos a avaliação dos autores do livro Topologias de Time, que oferece uma compreensão de como pode ser fácil ou difícil para os times construir, testar e manter seus serviços. Medindo a carga cognitiva do time, fomos capazes de aconselhar melhor nossas clientes sobre como mudar a estrutura de seus times e evoluir suas interações.

  • Uma arquitetura transicional é uma prática útil ao substituir sistemas legados. Assim como os andaimes podem ser construídos, reconfigurados e finalmente removidos durante a construção ou reforma de um edifício, muitas vezes você precisa de etapas arquiteturais provisórias durante o deslocamento do legado. As arquiteturas transicionais serão removidas ou substituídas posteriormente, mas não são trabalhos descartáveis, devido ao importante papel que desempenham para reduzir riscos e permitir que um problema difícil seja dividido em etapas menores. Dessa forma, ajudam a evitar a armadilha de adotar uma abordagem de substituição de legado "big bang", porque você não pode alinhar pequenos passos provisórios à visão final de arquitetura. É preciso ter cuidado para garantir que o "andaime" arquitetural seja eventualmente removido, para que não se torne dívida técnica mais tarde.

Avalie ?

  • Como você aborda a escrita de um bom código? Como você avalia se escreveu um bom código? Como pessoas desenvolvedoras de software, estamos sempre buscando regras, princípios e padrões interessantes que possamos usar para compartilhar linguagem e valores ao escrever código simples e fácil de alterar.

    Daniel Terhorst-North recentemente executou uma nova tentativa de criar uma lista de verificação para um bom código. Ele argumenta que, em vez de se ater a um conjunto de regras como SOLID, usar um conjunto de propriedades para visar é mais aplicável. Ele criou o que chama de propriedades CUPID para descrever o que devemos nos esforçar para alcançar um código "joyful": o código deve ser composable, seguir a filosofia Unix e ser previsível, idiomático e baseado em domínio.

  • Recomendamos que as organizações avaliem o design inclusivo como forma de garantir que a acessibilidade seja tratada como um requisito de primeira classe. Com muita frequência, os requisitos de acessibilidade e inclusão são ignorados até pouco antes, se não logo depois do lançamento do software. A maneira mais barata e simples de acomodar esses requisitos, além de fornecer feedback antecipado aos times, é incorporá-los totalmente ao processo de desenvolvimento. Anteriormente destacamos técnicas que executam um "shift-left" para segurança e requisitos multifuncionais. Uma perspectiva dessa técnica é atingir esse mesmo objetivo para acessibilidade.

  • Continuamos vendo o uso crescente do padrão Kubernetes Operator para outras finalidades além do gerenciamento de aplicativos implantados no cluster. O uso do padrão Operador para recursos não clusterizados se beneficia das definições de recursos personalizadas e do mecanismo de agendamento orientado a eventos implementado no plano de controle do Kubernetes para gerenciar atividades relacionadas ainda fora do cluster. Essa técnica se baseia na ideia dos serviços em nuvem gerenciados por Kube e a estende a outras atividades, como implantação contínua ou reação a mudanças em repositórios externos. Uma vantagem dessa técnica em relação a uma ferramenta específica é a ampla gama de ferramentas que vêm com o Kubernetes ou fazem parte de um ecossistema mais amplo. Você pode usar comandos como diff, dry-run ou apply para interagir com os recursos personalizados do operador. O mecanismo de agendamento do Kube facilita o desenvolvimento eliminando a necessidade de orquestrar as atividades na ordem correta. Ferramentas de código aberto como Crossplane, Flux e Argo CD se beneficiam desta técnica, e esperamos ver mais opções surgirem ao longo do tempo. Embora essas ferramentas tenham seus casos de uso, também estamos começando a ver o inevitável mau uso, ou uso excessivo dessa técnica, e precisamos repetir algumas recomendações antigas: só porque você pode fazer algo com uma ferramenta não significa que você deva fazer. Certifique-se de descartar abordagens convencionais mais simples antes de criar uma definição de recurso personalizada e se comprometer com a complexidade que acompanha essa abordagem.

  • A malha de serviços é geralmente implementada como um processo de proxy reverso, também conhecido como sidecar, implantado ao lado de cada instância de serviço. Embora os sidecars sejam processos leves, o custo geral e a complexidade operacional da adoção da malha de serviços aumentam a cada nova instância do serviço que exige outro sidecar. No entanto, com os avanços no eBPF, estamos observando uma nova abordagem de malha de serviços sem sidecar, na qual as funcionalidades da malha são enviadas com segurança para o kernel do sistema operacional, permitindo assim que os serviços no mesmo nó se comuniquem de forma transparente por meio de soquetes sem a necessidade de proxies adicionais. Você pode tentar isso com Cilium service mesh e simplificar a implantação de um proxy por serviço para um proxy por nó. Os recursos do eBPF despertaram nosso interesse, e achamos importante avaliar essa evolução da malha de serviço.

  • À medida que o software continua a crescer em complexidade, proteger o vetor de ameaças de dependências de software se torna cada vez mais desafiador. A recente vulnerabilidade do Log4J mostrou o quão difícil pode ser até mesmo conhecer essas dependências — muitas empresas que não usavam o Log4J diretamente estavam inadvertidamente vulneráveis ​​simplesmente porque outros softwares em seu ecossistema dependiam do mesmo. Supply-chain Levels for Software Artifacts, ou SLSA (pronuncia-se "salsa"), é um conjunto de orientações selecionadas por um consórcio para que as organizações se protejam contra ataques em cadeias de fornecimento, desenvolvido a partir de orientações internas que o Google vem usando há anos. Apreciamos o fato de SLSA não prometer uma abordagem "bala de prata" limitada a ferramentas para proteger a cadeia de fornecimento, em vez disso, fornecendo uma lista de verificação de ameaças e práticas concretas ao longo de um modelo de maturidade. O modelo de ameaça é fácil de seguir com exemplos reais de ataques e os requisitos fornecem orientações para ajudar as organizações a priorizar ações com base em níveis de robustez crescente para melhorar sua postura de segurança da cadeia de fornecimento. Acreditamos que SLSA fornece recomendações aplicáveis ​​e esperamos que mais organizações aprendam com o conjunto.

  • A necessidade de responder rapidamente aos insights de clientes impulsionou a crescente adoção de arquiteturas orientadas a eventos e processamento de fluxo. Frameworks como Spark, Flink ou Kafka Streams oferecem um paradigma no qual consumidores e produtores de eventos simples podem cooperar em redes complexas para fornecer insights em tempo real. Mas esse estilo de programação leva tempo e esforço para ser dominado e, quando implementado como aplicação de ponto único, carece de interoperabilidade. Fazer o processamento de fluxo funcionar universalmente em larga escala pode exigir um investimento significativo em engenharia. Agora, está surgindo uma nova safra de ferramentas que oferece os benefícios do processamento de fluxo para um grupo mais amplo e estabelecido de pessoas desenvolvedoras que se sentem à vontade usando SQL para implementar análises. A padronização do SQL como a linguagem de streaming universal reduz a barreira para a implementação de aplicações de dados de streaming. Ferramentas como ksqlDB e Materialize ajudam a transformar essas aplicações separadas em plataformas unificadas. Em conjunto, uma coleção de aplicações de streaming baseadas em SQL em uma empresa pode constituir um streaming data warehouse.

  • Até recentemente, a execução de um modelo de aprendizado de máquina (ML) era vista como algo caro do ponto de vista computacional e, em alguns casos, exigia hardware para fins especiais. Embora seu processo de criação ainda esteja amplamente incluído nessa classificação, os modelos podem ser construídos de maneira a permitir sua execução em dispositivos pequenos, de baixo custo e baixo consumo de energia. Essa técnica, chamada TinyML, abriu a possibilidade de execução de modelos de ML em situações que muitas pessoas considerariam inviáveis. Por exemplo, em dispositivos alimentados por bateria ou em ambientes desconectados, com conectividade limitada ou irregular, o modelo pode ser executado localmente sem um custo proibitivo. Se você está pensando em usar ML, mas achou que seria algo irreal devido às restrições de computação ou rede, vale a pena avaliar essa técnica.

Evite ?

  • Para organizações que usam Azure como provedor de nuvem principal, Azure Data Factory (ADF) é atualmente o padrão para orquestrar pipelines de processamento de dados. O serviço oferece suporte à ingestão de dados, copiando dados de/para diferentes tipos de armazenamento locais, ou no Azure, e executando a lógica de transformação. Embora nossa experiência com o ADF tenha sido adequada para migrações simples de armazenamentos de dados local para a nuvem, desencorajamos o uso do Azure Data Factory para orquestração de fluxos de trabalho e pipelines de processamento de dados complexos. Tivemos algum sucesso usando ADF principalmente para mover dados entre sistemas. Para pipelines de dados mais complexos, ainda há desafios, incluindo depuração e relatórios de erros pobres; observabilidade limitada, já que os recursos de log do ADF não se integram a outros produtos, como Azure Data Lake Storage ou Databricks, dificultando a implementação de uma observabilidade de ponta a ponta; e disponibilidade de mecanismos de acionamento de fontes de dados apenas para determinadas regiões. No momento, incentivamos o uso de outras ferramentas de orquestração de código aberto (por exemplo, Airflow) para pipelines de dados complexos, limitando ADF para cópia de dados ou snapshots. Nossos times continuam usando o Data Factory para mover e extrair dados, mas para operações maiores, recomendamos outras ferramentas de fluxo de trabalho mais completas.

  • Anteriormente, apresentamos times de produto de engenharia de plataforma em Adotar como uma boa maneira de operar para equipes de plataformas internas, permitindo assim que times de entrega habilitem o autoatendimento para implantação e operação de sistemas com tempo de espera e complexidade de stack reduzidos. Infelizmente, estamos vendo o rótulo de "time de plataforma" aplicado a equipes dedicadas a projetos que não têm resultados nítidos ou um conjunto bem definido de clientes. Como resultado, esses times de plataforma genéricos encontram dificuldades para entregar devido às altas cargas cognitivas e à falta de alinhamento de prioridades, pois estão lidando com uma coleção variada de sistemas não relacionados. Dessa forma, tornam-se efetivamente equipes genéricas de suporte geral para coisas que não se encaixam ou que são indesejadas em outros lugares. Continuamos acreditando que os times de produto de engenharia de plataforma com foco em um produto (interno) bem definido oferecem um melhor conjunto de resultados.

  • Continuamos a perceber dados de produção em ambientes de teste como uma área de preocupação. Em primeiro lugar, muitos exemplos dessa prática resultaram em danos à reputação, por exemplo, quando um alerta incorreto foi enviado de um sistema de teste para toda uma base de clientes. Em segundo lugar, o nível de segurança, especificamente em torno da proteção de dados privados, tende a ser menor para sistemas de teste. Não adianta ter controles elaborados sobre o acesso aos dados de produção se esses dados forem copiados para um banco de dados de teste que pode ser acessado por todas as pessoas desenvolvedoras e QAs. Embora seja possível ofuscar os dados, isso tende a ser aplicado apenas a campos específicos, por exemplo, números de cartão de crédito. Por fim, copiar dados de produção para sistemas de teste pode violar as leis de privacidade, por exemplo, quando os sistemas de teste são hospedados em ou acessados ​​de um país ou região diferente. Este último cenário é especialmente problemático com implantações de nuvem complexas. Dados falsos são uma abordagem mais segura e existem ferramentas que ajudam a criá-los. Reconhecemos que existem razões para que elementos específicos dos dados de produção sejam copiados, por exemplo, para reprodução de bugs ou treinamento de modelos de ML específicos. Aqui, nosso conselho é proceder com cautela

  • Geralmente evitamos colocar blips no anel Evite quando consideramos uma recomendação muito óbvia, por exemplo, seguir cegamente um estilo de arquitetura sem prestar atenção às compensações. No entanto, a grande prevalência de times que escolhem uma aplicação de página única (SPA) por padrão quando precisam de um site nos despertou a preocupação de que as pessoas não estejam nem mesmo reconhecendo SPAs como um estilo de arquitetura — em vez disso, saltando imediatamente para a seleção de framework. SPAs incorrem em uma complexidade que simplesmente não existe em sites tradicionais baseados em servidor: otimização de mecanismo de pesquisa, gerenciamento de histórico do navegador, web analytics, tempo de carregamento da primeira página etc. Essa complexidade é frequentemente justificada por questões de experiência de uso (embora a rotatividade em torno do gerenciamento de estado na comunidade React indique o quão difícil pode ser obter uma solução de aplicação geral). Muitas vezes, porém, não vemos os times fazendo essa análise de compensação, aceitando cegamente a complexidade da prática de SPA como padrão, mesmo quando as necessidades de negócio não justificam. De fato, começamos a perceber que muitas pessoas desenvolvedoras mais inexperientes nem sequer estão cientes da existência de uma abordagem alternativa, pois passaram toda a sua carreira em um framework como o React. Acreditamos que muitos sites se beneficiarão da simplicidade da lógica do lado do servidor e técnicas que ajudam a fechar a lacuna na experiência de uso, como Hotwire, são encorajadoras.

 
  • techniques quadrant with radar rings Adote Experimente Avalie Evite Adote Experimente Avalie Evite
  • Novo
  • Modificado
  • Sem alteração

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 faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

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 faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

Radar

Baixar o Technology Radar Vol.26

English | Español | Português | 中文

Radar

Mantenha-se por dentro das tendências de tecnologia

 

Seja assinante

Visite nosso arquivo para acessar os volumes anteriores