Forem: Pode me chamar de Juscélio Reis

Integrações como estratégia para acelerar a colaboração no Open Insurance

Pode me chamar de Juscélio Reis — Mon, 26 Dec 2022 13:51:34 +0000

Preciso defender o potencial comercial que as APIs desbloqueiam. Construir uma estratégia de compartilhamento de dados utilizando como fundação "as APIs", pode apresentar grandes benefícios para o negócio, assim como para outros domínios. Isto é ainda mais verdadeiro quando discutimos Open Insurance ou Sistema de Seguros Aberto - o ponto de venda desta abordagem é muitas vezes um foco no eventual valor comercial que é desbloqueado. Embora este potencial seja importante, o Open Insurance tem impactos ainda mais dramáticos e de longo prazo em diversas áreas de trabalho.

O que queremos dizer com integração?

Em um nível básico, integração é o processo de unir diferentes coisas. Uma das frustrações que ouvimos frequentemente dos usuários é que sua tecnologia não se conecta completamente: ainda há muito retrabalho "manual" para correlacionar as informações de um sistema com o outro e muitas vezes você, ou o cliente, tem que acessar múltiplos sistemas para completar a jornada do cliente, sem mencionar na quantidade de erros encontrados nesse processo.

Em um mundo ideal, você quer que os sistemas compartilhem informações automaticamente para não ter que reinscrever nenhum dado do cliente. Ao mesmo tempo, você quer ser capaz de se mover sem problemas entre diferentes ferramentas de aconselhamento sem o inconveniente de sair de uma e entrar em outra. Você precisa que seus sistemas falem uns com os outros, compartilhem dados e continuem os processos com o mínimo de intervenção manual, racionalizando a experiência do usuário para criar uma jornada única e direta para o colaborador da empresa ou para o cliente.

Open Insurance e a mentalidade de colaboração

O que este mandato está expressando, e o que Open Insurance está baseado, é o conceito de que todos os dados, comunicação e funcionalidade devem acontecer em um conjunto comum de interfaces, independentemente da empresa (Seguradora ou outra entidade) ou da intenção. As equipes de vendas devem se comunicar através deste conjunto de interfaces, e as APIs padrão devem servir como entidades unificadoras entre todas elas.

Então, com esse entendimento, o que o Open Insurance pode realmente desbloquear no sentido de acelerar a colaboração entre as entidades?

Fluxos de trabalho unificados

O Open Insurance cria fluxos de trabalho comuns e unificados. Como os APIs em questão são negociados como a principal modalidade de comunicação, os caminhos são formalizados. Isto leva a canais de comunicação claros para as equipes existentes, permitindo um maior nível de sincronicidade e comunicação. Para novas entidades, este benefício proporciona uma integração mais rápida e fácil dos fluxos existentes em novos sistemas, pois o resultado desejado (caminhos comuns) já está fundamentalmente embutido no dia a dia da organização.

Aprimorar a descoberta dos serviços

Da mesma forma, adotar um conjunto comum de comunicação leva a uma melhor descoberta, unifica o conjunto de informações para cada tipo de seguro e facilita o entendimento do fluxo de dados que cada entidade utiliza. Isto acaba por reduzir o atrito na busca de informações e de dados, criando uma fonte única da verdade.

Reusabilidade

Um dos benefícios mais fortes do Open Insurance é que ele força as organizações a considerar a realidade das tecnologias que elas utilizam. E como seu processo será utilizado por outras organizações. Quando APIs comuns constituem o núcleo de todas as interações comerciais, tanto os dados quanto a funcionalidade do Open Insurance estão abertos para aqueles que podem querer usá-los. Esta superfície permite a reusabilidade do valor comercial central na organização, liberando um enorme potencial e capacidade iterativa para colaboração entre as entidades.

O Santo Graal da integração

Enquanto alguns sistemas só precisam transferir dados para uma direção, o Open Insurance muda essa logica pois quanto mais dados forem compartilhados, melhor, por exemplo, a transferência de dados entre seu sistema de back office e seu portal do cliente, plataforma ou ferramenta de planejamento de fluxo de caixa e vice-versa. As integrações bidirecionais permitem uma jornada direta de ponta a ponta, com maior automação das tarefas, eliminando os aspectos mais desafiadores do processo de corretagem e dando a você mais tempo para se concentrar em seus clientes.

Este compartilhamento bidirecional de dados é o Santo Graal na racionalização do processo de corretagem e o modelo do Open Insurance nos dá uma base sólida para construir estas integrações mais profundas. No entanto, ainda requer que todos os participantes trabalhem juntos para aproveitar ao máximo a tecnologia.

Medir o desempenho dos produtos e serviços de software

Pode me chamar de Juscélio Reis — Wed, 30 Nov 2022 21:25:27 +0000

Há muitas frameworks e metodologias que visam melhorar a forma como construímos produtos e serviços de software. Com tanto material é necessário entender o que funciona e o que não funciona para ~~nossa~~ sua realidade. E existem métricas que são famosas, mas que estudos mostra como essas métricas ~~famosas~~ são ineficientes.

Google DORA

Vou iniciar explicado as mais famosas no momento, Google DORA (acrônimo para "Dev*Ops and **Research and **A*ssessment") são um conjunto de métricas que o famoso Google utiliza para realizar um benchmarking com equipes reais desde 2018, mas informação aqui. Dessa forma é fácil para aqueles gestores que desejam comparar a desempenho da sua equipe em relação a outras empresas.

Lead Time (Deploy Cycle Time)

A definição do Lead Time é o tempo entre a "promessa do time" até o "código funcionando com sucesso na produção". Essa métrica é utilizada para saber quanto tempo leva para implantar uma funcionalidade em um ambiente de desenvolvimento, teste ou produção. Tem o objetivo de melhorar os métodos, processos e ferramentas utilizado pela organização.

Deployment Frequency

A segunda métrica a ser considerada é o tamanho das entregas. A redução do tamanho da entrega é outro elemento central do paradigma Lean. A redução do tamanho das entregas reduz o tempo e a variação da cadência, acelera o feedback, reduz os riscos e as despesas gerais, melhora a eficiência, aumenta a motivação e a urgência e reduz os custos e o crescimento do cronograma.

Mean Time to Restore

Uma constante no desenvolvimento de software é que as falhas vão existir (Esse artigo comenta sobre como é inevitável existir software sem falhas). Um gestor de excelência precisa saber dessa verdade e se perguntar: Com que rapidez o meu time consegue restaurar o serviço?

Change Fail Rate

Essa métrica observa qual o impacto das mudanças no ambiente de produção, ou se preferir, qual a quantidade de falhas as novas funcionalidades estão entregando para os usuários. O quanto o serviço é degradado pelas novas funcionalidades?

Desempenho operacional (confiabilidade)

O relatório de 2022 foi apresentado uma quinta métrica, desempenho operacional ou se preferir a confiabilidade. A confiabilidade é a medida que busca entender como suas entregas atende a expectativa do dos usuários, tais como disponibilidade e desempenho. Engenharia de confiabilidade é um assunto bem vasto e cabe um artigo somente para esse assunto. O estudo expandiu seu conceito em 2021 para medir a confiabilidade, visando assim representar a disponibilidade, latência, desempenho e escalabilidade de forma mais ampla.

Relatório de 2022

O Google disponibilizou os resultados para o ano de 2022. Esta interessando de saber se sua equipe é de alto, médio ou baixo desempenho?

Métricas depreciadas (tente não usar essas métricas)

Agora apresento duas métricas para não utilizar. Essas métricas podem ser consideradas frágeis, e por essa razão não é uma boa indicação confiar decisões estratégicas com base em uma métrica que "depende" muito do contexto ou que possui um grau de confiança muito baixo.

Code Churn

Code Churn, é a medida que calcula a taxa de reescrita de um software ou a quantidade de linhas excluídas logo após ser escrito, é uma parte normal do processo de desenvolvimento.

Tem como premissa calcular se o desenvolvedor está tendo muito retrabalho ou se as solicitações não são claras o suficiente e está sobrecarregando o desenvolvedor e este esta gastando tempo com algo que não vai mais ser necessário.

Mas o é possível que os desenvolvedores apenas estão testando hipóteses e exploram várias soluções para um problema - especialmente para o início de um projeto, quando o problema ainda não tem uma solução clara.

Agora o problema pode estar relacionado com outros fatores que fogem do controle do desenvolvedor. Tais como requisitos que não estão claros, stakeholder indecisos, um problema realmente complicado, o desenvolvedor esta apenas criando um protótipo, o desenvolvedor está polindo (apenas uma mudança, pois essa pessoa tem um TOC), ou o código não tem um bom direcionamento e fica alternando o seu proposito com certa frequência.

De todo o modo, é complicado compreender o comportamento de uma pessoa ou equipe.

Lines of Code

Essa métrica apresenta um grande problema para as linguagens de programação atuais. Pois para ter um grau satisfatório existem várias variáveis que o desenvolvedor (alvo da métrica) pode manipular conforme desejar. Antigamente existiam ~~ainda existem~~ linguagens de programação que obrigava o desenvolvedor seguir um padrão de ideação (forma como escrevemos um código). Assim era possível medir a produtividade do desenvolvedor com base na quantidade de linhas que ele escrevia.

Mas atualmente as linguagens permitem mudar essa tal de indentação, ou seja, posso escrever todo um sistema em apenas uma linha ou escrever usando 1000 linhas.

Se um desenvolvedor sabe que sua produtividade está com base na quantidade de linhas, é possível que essa pessoa inclua linhas sem sentido ou faça da maneira mais complicada somente com o objetivo de inflar sua avaliação.

Olha esse exemplo, é possível escrever um simples programa que mostra a mensagem "Olá mundo".

Não tem como inferir que o com mais linha tem mais funcionalidade ou mais qualidade.

Divida técnica: O bureau de crédito da TI

Pode me chamar de Juscélio Reis — Mon, 31 Oct 2022 15:39:14 +0000

É comum falar que qualidade do código gerado pelo time de desenvolvimento pode gerar perdas financeiras, afinal qual o impacto financeiro em deixar de corrigir um bug no software da empresa? Vou gastar mais dinheiro para corrigir esse bug?

Conseguir mensurar todas as possibilidades é uma tarefa complexa e ouso afirmar que não existe um método para garantir com exatidão (exceto para o Doutor Estranho), precisamos sempre trabalhar com possibilidades. Porem é possível olhar para trás e perceber que algumas decisões foram ruins e provocaram algum prejuízo financeiro. O caso mais ilustre é o erro de 1 bilhão de dólares:

O erro de 1 bilhão de dólares

Tony Hoare: O criador do algoritmo QuickSort e também vencedor do Prêmio Turing (o Prêmio Nobel de Computação) acrescentou uma funcionalidade simples na linguagem Algol com o intuito de melhorar a performance das aplicações escritas nessa linguagem, o motivo fazia total sentido na época porque parecia prático e fácil de fazer. Várias décadas depois, ele mostrou seu arrependimento em uma conferencia:

Eu o chamo de meu erro de um bilhão de dólares... Naquela época, eu estava projetando o primeiro sistema de tipo abrangente para referências em uma linguagem orientada a objetos. Meu objetivo era garantir que todo o uso de referências fosse absolutamente seguro, com verificação realizada automaticamente pelo compilador.
Mas não consegui resistir à tentação de colocar uma referência nula, simplesmente porque era muito fácil de implementar. Isto levou a inúmeros erros, vulnerabilidades e falhas de sistema, que provavelmente causaram um bilhão de dólares de dor e danos nos últimos quarenta anos.
– Tony Hoare, inventor of ALGOL W.

Versão original:

I call it my billion-dollar mistake…At that time, I was designing the first comprehensive type system for references in an object-oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler.
But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
– Tony Hoare, inventor of ALGOL W.

Pode encontrar nesse link o vídeo completo dessa conferencia.

Impactos da divida técnica

Você acredita que uma dívida técnica possui impacto que vai além do desperdício financeiro?

Vamos imaginar essa divida técnica como sendo uma operação de crédito financeiro, e o nome Divida técnica como sendo a medida que o bureau de crédito da TI utiliza para controlar seu cadastro. Se não pagamos essa divida em dia, podemos ter nosso nome inscrito em um cadastro e como consequência sofrer limitações futuras.

O serviço de proteção ao crédito, ou bureau de crédito, é um serviço de informações de crédito, que utiliza informações de adimplência e inadimplência de pessoas físicas ou jurídicas para fins de decisão sobre crédito.

Se você já teve nome sujo, bancos podem negar crédito para o resto da vida. Agora o mesmo pode acontecer com o não gerenciamento da dívida técnica. Como consequência, a velocidade de entrega do time é limitada. É possível contratar mais profissionais para fazer o mesmo trabalho. Em resumo, gastamos mais recursos financeiros para entregar menos funcionalidades. Duvida?

A lei de Brooks é uma observação sobre gerenciamento de projetos de software, segundo a qual adicionar mão de obra ao projeto de software que está atrasado o atrasa ainda mais. Foi cunhado por Fred Brooks em seu livro de 1975 O mítico homem-mês: ensaios sobre engenharia de software.

Se não é simples correlacionar o impacto financeiro com o bug, podemos analisar o impacto da dívida técnica na produtividade desses times. Pesquisas recentes sugerem que a empresa média perde 23-42% do tempo dos desenvolvedores devido a dívidas técnicas e código ruim em geral 1. Outro dado interessante é que os desenvolvedores de software são frequentemente "forçados" a introduzir novas dividas técnicas à medida que as empresas mantêm a qualidade do código comercial para ganhos a curto prazo, como novas funcionalidades 2.

A dívida técnica afeta tanto a felicidade dos desenvolvedores quanto a sua satisfação no trabalho 3. Nem sempre um profissional larga a empresa por motivos financeiros, existem outros fatores que precisam ser considerados. Além de perder um recurso, perde o conhecimento desse profissional, como mensurar o impacto financeiro dessa perda?

Por que isso acontece?

Em mais de 13 anos de experiencia consigo listar essas desculpas como sendo as mais comuns:

Não temos tempo para testar essa alteração, vamos colocar em produção e assim vamos monitorar o ambiente para saber o que vai acontecer.

Existe um processo de gestão de mudança (GMUD), mas ele é tão complicado que se for seguido a próxima janela de implementação é só daqui 2 meses, e o cliente precisa dessa funcionalidade agora.

O nosso ambiente de teste não esta atualizado ou não esta pronto. Isso quando não existe a resposta: o ambiente de teste é em produção (junto com nossos clientes).

Recomendo a leitura do livro O projeto fênix: um romance sobre TI, DevOps e sobre ajudar o seu negócio a vencer, esse livro não possui uma linguagem excludente, vulgo techniques, se trata de uma novela da área de TI. Um pouco da historia: O time de Operações de TI é olhado por todos como causadores de problemas, além de estarem sempre atrapalhando o andamento do Projeto Fênix, cujo objetivo é salvar a empresa. Como consequência não é possível alocar as pessoas certas da empresa em projetos estratégicos pois precisam apagar focos de incêndio, soa familiar?

O papel da governança

Um estudo do IDC previu em 2019 que em 2022, 90% dos Novos Serviços Digitais serão construídos como aplicações compostas usando serviços públicos e internos fornecidos por API; Metade desses serviços irá alavancar a IA e o aprendizado de máquinas.

Se um desses serviços está com uma dívida muito alta pode criar um efeito cascata e prejudicar outros serviços. Seria algo assim...

Bem, importância de uma base de código saudável é amplamente subvalorizada no nível empresarial: mais de 90% dos gerentes de TI carecem de processos e estratégias para o gerenciamento da dívida técnica 4.

Agora para ter uma organização de alto desempenho, precisamos ser sensíveis às necessidades dos clientes, agir com base em feedback e continuar a inovar se quisermos permanecer relevantes no mercado. E precisamos fazer isso durante ciclos de produtos cada vez mais curtos. E para gerenciar essa dívida técnica é necessário uma área especializada e dedicada para fomentar estratégia focando nos processos, programa e pessoas capacitadas.

TIC: por onde começar

Pode me chamar de Juscélio Reis — Mon, 24 Oct 2022 18:44:57 +0000

O mercado de TIC

Não sabe o que é Tecnologia da Informação (TI) ou Tecnologia da Informação e Comunicação (TIC)? E não conhece o potencial desse mercado, segue alguns números do relatório da Brasscom de 2021:

A remuneração média de TI in House* é de R$ 5.805 sendo 2,9 vezes maior que o salário médio nacional (dados referente a agosto de 2021).
Para os próximos 4 anos existe uma demanda de 673.502 profissionais.
O crescimento do Setor TIC em 2021 foi de 36.4%.

A Brasscom, Associação das Empresas de Tecnologia da Informação e Comunicação (TIC) realiza um estudo anual sobre a distribuição das oportunidades de emprego para o setor de tecnologia.

E se esta pensando que isso é uma tendência isolada para o mercado de São Paulo, melhor repensar sobre o assunto, a tendência está em todo o Brasil, olha aqui esse gráfico:

Distribuição dos empregos de TIC e Telecom no Brasil em 2021 (Fonte: Brasscom)

A área de TIC tem oportunidadeS para você, caro leitor! Se começar agora uma faculdade e estudar por 2 ou 4 anos (depende do curso) ainda vai existir muita oportunidade sobrando para iniciar sua carreira.

Para quem deseja começar agora na área, existem alguns atalhos (pelo menos no momento). Mas entenda que esses atalhos não significam que o caminho será fácil, e que vai precisar continuar a estudar por 2, 4, 6 ou 20 anos.

A área de tecnologia é exigente com os seus profissionais, estudar muito é obrigatório. Aceita os termos?

Opções para começar

Agora vou apresentar algumas opções para começar na área de TI, o melhor caminho será decisão sua. Abaixo segue uma lista, e vou incluir alguns sites para cada uma dessa opções:

Cursos rápidos

Os cursos rápidos servem vários objetivos para pessoas diferentes podem ser utilizados para conectar as diferentes etapas do estudo académico, ou para obter formação profissional e melhorar suas qualificações.

Cursos livres seriam plataformas de educação ou escolas que ofertam cursos presenciais, vou focar nos cursos online. Essas são as plataformas que eu recomendo:

Alura (pago).
Coursera (gratuito ou pago).
edX (gratuito ou pago).
LINUXtips (pago, existem campanhas gratuitas).
Microsoft Learn (gratuito).
Pluralsight (pago, com um período gratuito).
Rocketseat (gratuito).
Udemy (pago, com alguns cursos gratuitos).
Universidade Brasileira Livre (gratuito).

Como podem perceber, algumas opções são gratuitas, mas estão disponíveis apenas no idioma inglês. Outras plataformas em português em sua grande parte estão cobrando um valor para acessar o seu catalogo.

Vale ressaltar que a LINUXtips tem uma peculiaridade bem interessante. É uma plataforma paga, mas eles costumam fazer campanhas para oferecer cursos gratuitos para um público bem diversificado. Vale a pena procurar a LINUXtips para saber mais.

Particularmente eu recomendo esses cursos aqui:

Cursos técnicos

Cursos técnicos recomendo muito para o adolescente que ainda está no ensino médio e já sabe que quer seguir o caminho da tecnologia.

O Senai possui cursos na modalidade presencial espalhado pelo Brasil e também possui a opção por curso a distância.

Senai

Faculdade

Mesmo sabendo que não é obrigatório para muitas vagas de emprego, procurem concluir um curso de nível superior. Mesmo que demore, todo esforço em educação é recompensado.

Para o dia a dia, não faz diferença se o curso é Ciência de Computação, Sistemas de Informação, Analise e Desenvolvimento de Sistemas ou Engenharia da Computação. A escolha é toda sua, a diferença será na duração do curso e na grade de disciplina de cada um desse curso.

Algumas vagas exigem que o profissional tenha formação de nível superior. Dessa forma você terá mais oportunidades.

Programas de bootcamp

Um bootcamp é um tipo de treinamento imersivo feito para o desenvolver habilidades técnicas onde o futuro profissional de tecnologia absorva o conhecimento teórico de maneira conjunta com a prática. No universo de TIC, essa modalidade está ganhando cada vez mais força no mercado. Essa é a opção mas vantajosa na minha humilde opinião, e sendo honesto iniciei minha carreira realizando um bootcamp, na época tinha outro nome Student to Business (S2B) uma parceria entre a Microsoft e o Senai-DF.

Em um bootcamp, os alunos vivenciam um treinamento imersivo com profissionais com experiência de mercado, que vão ajudá-los a começar seus primeiros projetos num curto espaço de tempo. Inclusive, o tempo é um fator determinante neste tipo de curso, geralmente com algumas semanas de duração.

Um bom bootcamp oferece uma parceria com alguma empresa que esta buscando por profissionais qualificados. Por esse experiencia posso recomendar a XP Educacao e a Trybe. Eu já tive o prazer de trabalhar com as duas plataformas, dentro da Wiz Soluções.

Nesse momento, Wiz esta realizando a 3ª edição do programa Speed Wiz Dev, tive a oportunidade de acompanhar as 2 edições anteriores e conheci vários profissionais super hiper mega qualificados.

Vagas para o 3ª edição do Speed Wiz Dev

Algumas matérias sobre versões passadas do Speed Dev Wiz:

Wiz e IGTI atraem 4,5 mil pessoas em programa de desenvolvedores de software

Cuidado! Os programas de bootcamp é um meio para começar, e lembre que ao terminar um bootcamp não é o fim do treinamento, é apenas o início da sua carreira. Esse início pode ser bastante assustador, nesse momento é muito importante ter um padrinho que o acolha durante os primeiros meses, esse padrinho terá um papel fundamental para te ajudar com os problemas do dia a dia.

E lembre que errar faz parte, e não saber nada é normal e que o aprendizado é um processo lento e demorado. Dessa forma só posso aconselhar a não desistir e continue estudando, que o resultado virá.

GC: Otimizando para o ambiente do Azure

Pode me chamar de Juscélio Reis — Sun, 07 Feb 2021 15:24:40 +0000

Neste artigo, pretendo abordar um assunto complicado e que pode ser usado para melhorar nossas aplicações hospedados na nuvem da Microsoft Azure. Vou abordar o que exatamente acontece durante a coleta de lixo (GC) e como diferentes modos de GC podem afetar significativamente o desempenho do aplicativo. Mas antes vamos entender qual o ambiente que estamos executando nossas aplicações.

Azure

O que mais consumimos do Azure aqui na Wiz é o serviço de Aplicativo, ou se preferir chamar App Service. Esse serviço quando criado é composto de alguns nomes ou outros serviços. Sendo eles:

App Service Plan (Plano de Serviço de Aplicativo): Um Plano de Serviço de Aplicativo consiste nas máquinas virtuais alocadas que hospedarão os Serviços de Aplicativo do Azure. Possui vários níveis, do Gratuito ao Premium, seu orçamento é o limite. O Plano de Serviço de Aplicativo define a região do servidor físico onde seu aplicativo será hospedado e a quantidade de armazenamento, RAM e CPU que os servidores físicos terão.
App Service (Serviço de Aplicativo): O Serviço de Aplicativo do Azure é um serviço baseado em HTTP para hospedar aplicativos da web, APIs REST e back-ends móveis.
Resource Group (grupo de recursos): Um grupo de recursos é um conjunto que contém recursos relacionados para uma solução do Azure. O grupo de recursos pode incluir todos os recursos da solução ou apenas os recursos que você deseja gerenciar como um grupo.

Agora que temos a nomenclatura do Azure para os serviços de APIs, vamos observas os planos de serviço, ou como aprendemos, vamos olhar nas opções do App Service Plan. Podemos dividir esse plano de serviço em três categorias:

Computação compartilhada: Free ou F1 e Shared, as duas camadas de base, executa um aplicativo na mesma VM do Azure que outros aplicativos de serviço de aplicativo, incluindo aplicativos de outros clientes. Essas camadas alocam cotas de CPU para cada aplicativo executado nos recursos compartilhados, e os recursos não podem ser escalonados. Esse plano possui um limite de tempo e não permite a opção de configurar as apis em dotnet como 64 bits. Esse plano é um grande problema para nossas apis, pois a combinação do dotnet core 3.1 com uma configuração de 32 bits vai resultar em erro de estouro de memória, em outras palavras não usem em ambiente de homologação ou produção.
Computação dedicada: as camadas Basic, Standard, Premium, PremiumV2 e PremiumV3 executam aplicativos em VMs do Azure dedicadas. Somente aplicativos no mesmo App Service Plan compartilham os mesmos recursos de computação. Quanto mais alto o nível, mais instâncias de VM estão disponíveis para você escalar horizontalmente. Essa é a opção que usamos em homologação e produção, em sua grande maioria usamos o plano S1 ou Standard 1, em alguns casos usamos o plano B1 ou Basic, lembrando que não é recomendado pela Microsoft a utilização do plano Basic para produção.
Isolado: esta camada executa VMs do Azure dedicadas em Redes Virtuais do Azure dedicadas. Ele fornece isolamento de rede além do isolamento de computação para seus aplicativos. Ele fornece os recursos de expansão máxima. No momento vamos ignorar esse modo aqui.

Preste atenção aqui

O plano B1 possui 1 núcleo de CPU e 1.75 GB de ram, pode receber até 3 instancias de aplicativos, além de outras limitações do plano Basic. Mais informação aqui.

O plano S1 possui 1 núcleo de CPU e 1.75 GB de ram, mas pode receber até 10 instancias de aplicativos, além de outras limitações do plano Standard. Mais informação aqui.

Bom agora podemos voltar ao tema principal desse artigo garbage collection ou GC pros íntimos.

Garbage Collection

Vou colocar um pequeno resumo do GC aqui, só para entender qual o seu papel no nosso ambiente computacional. Mas será um breve resumo, mais informação ler esse artigo aqui.

O garbage collection (GC) atua como um gerenciador de memória automático. O garbage collection gerencia a alocação e liberação de memória para um aplicativo. O gerenciamento automático de memória pode eliminar problemas comuns, como esquecer de liberar um objeto e causar um vazamento de memória ou tentar acessar a memória de um objeto que já foi liberado.

A coleta de lixo ocorre quando uma das seguintes condições é verdadeira:

O sistema está com pouca memória física. Isso é detectado pela notificação de memória insuficiente do sistema operacional ou memória insuficiente, conforme indicado pelo host.
A memória usada por objetos alocados no heap gerenciado ultrapassa um limite aceitável. Este limite é continuamente ajustado conforme o processo é executado.
O método GC.Collect é chamado. Em quase todos os casos, você não precisa chamar esse método, porque o coletor de lixo é executado continuamente. Este método é usado principalmente para situações e testes únicos.

O algoritmo GC é baseado em várias premissas:

É mais rápido compactar a memória para uma parte do heap gerenciado do que para todo o heap gerenciado.
Objetos mais novos têm vida útil mais curta e objetos mais antigos têm vida útil mais longa.
Objetos mais novos tendem a estar relacionados entre si e acessados pelo aplicativo ao mesmo tempo.

Como vemos a estratégia do GC é dividir o heap em partes considerando a idade dos objetos para otimizar o desempenho, o heap gerenciado é dividido em três gerações, 0, 1 e 2.

Geração 0: Esta é a geração mais jovem e contém objetos de curta duração. Um exemplo de objeto de vida curta é uma variável temporária. A coleta de lixo ocorre com mais frequência nesta geração.
Geração 1: Esta geração contém objetos de vida curta e serve como um buffer entre objetos de vida curta e objetos de vida longa.
Geração 2: Esta geração contém objetos de vida longa. Um exemplo de objeto de longa duração é um objeto em um aplicativo de servidor que contém dados estáticos que estão ativos durante o processo. Mais um motivo para nunca encher nossa aplicação com objetos estáticos.

Objetos que não são recuperados em uma coleta de lixo são conhecidos como sobreviventes e são promovidos para a próxima geração:

Os objetos que sobrevivem a uma coleta de lixo da geração 0 são promovidos para a geração 1.
Os objetos que sobrevivem a uma coleta de lixo da geração 1 são promovidos para a geração 2.
Os objetos que sobrevivem a uma coleta de lixo da geração 2 permanecem na geração 2.

Até aqui podemos entender que os objetos da geração 0 e 1 são os mais voláteis ou como está na documentação são objetos efêmeros. Já os objetos da geração 2 são mais permanentes então não faz tanto sentido fazer uma coleta de lixo completa, podemos focar mais nas gerações 0 e 1 que vamos obter mais sucesso. Mais um motivo para evitar a utilização de objetos estáticos e de tentar chamar o GC.Collect manualmente.

*Estamos chegando na parte de otimização, até aqui foi um grande resumo do resumo para começar o processo de otimização. *

O tamanho do segmento efêmero varia dependendo se um sistema é de 32 ou 64 bits e do tipo de coletor de lixo que está executando (Workstation ou Server GC). A tabela a seguir mostra os tamanhos padrão do segmento efêmero.

Workstation/server GC	32-bit	64-bit
Workstation GC	16 MB	256 MB
Server GC	64 MB	4 GB
Server GC with > 4 logical CPUs	32 MB	2 GB
Server GC with > 8 logical CPUs	16 MB	1 GB

Acabamos de saber que o existem dois tipos de GC, um chamado Workstation GC e outro chamado Server GC. Bora entender esses caras, pois aqui está a chave para a otimização das nossas APIs que estão executando no Azure. Se não entendeu olha o tamanho que elas possuem no ambiente de 64 bits e compara com o tamanho do App Service Plan B1 e S1, vai perceber que a matemática não vai bater.

O GC é inteligente e pode funcionar em uma ampla variedade de cenários. No entanto, podemos definir o tipo de GC com base nas características da carga de trabalho, em outras palavras de acordo com o App Service Plan. O dotnet fornece os seguintes tipos de GC:

Workstation: GC da estação de trabalho, que é projetada para aplicativos cliente. É o padrão do GC para aplicativos independentes. Para aplicativos hospedados, por exemplo, aqueles hospedados pelo ASP.NET, o host determina o padrão do GC. Vai um spoiler vai ser o tipo Server.
Server: GC que se destina a aplicativos de servidor que precisam de alto rendimento e escalabilidade.

Otimização

Aqui é onde vou citar o blog da microsoft, a visão que eles possuíam do ambiente de hospedagem das aplicações dotnet:

Keep in mind that it’s very common to run only one server process on a dedicated machine so you don’t get into this situation.
-- Maoni, Workstation GC for server applications?

Não é o que estamos utilizando no contexto atual, usamos servidores com 1 núcleo e 1.75GB de ram para hospedar de 3 a 10 aplicações. Essa é a questão!!! Precisamos mudar o padrão e utilizar como uma aplicação que vai funcionar na máquina do cliente em outras palavras precisamos sair do Server GC para o Workstation GC. Mas ao começar essa otimização precisamos alterar uma tag no .Api.csproj, vamos colocar a tag *ServerGarbageCollection como false. Mais informação aqui.

Porem ao alterar essa tag precisamos alterar outra ConcurrentGarbageCollection para false, se você está executando várias instâncias de aplicativo, considere o uso do Workstation GC com a coleta de lixo simultânea desabilitada, ConcurrentGarbageCollection false. Isso resultará em menos troca de contexto, o que pode melhorar o desempenho.

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
    <IncludeOpenAPIAnalyzers>true</IncludeOpenAPIAnalyzers>
    <ServerGarbageCollection>false</ServerGarbageCollection>
    <ConcurrentGarbageCollection>false</ConcurrentGarbageCollection>
  </PropertyGroup>

Fiz um teste e você pode ver como a combinação de ServerGarbageCollection false com ConcurrentGarbageCollection true aumenta o tempo de processamento.


BenchmarkDotNet=v0.12.1, OS=ubuntu 20.04
Intel Core i7-7500U CPU 2.70GHz (Kaby Lake), 1 CPU, 2 logical cores and 1 physical core
.NET Core SDK=3.1.405
  [Host]                : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Server                : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  ServerConcurrent      : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Workstation           : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  WorkstationConcurrent : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT

IterationCount=15  LaunchCount=2  WarmupCount=10

Method	Job	Concurrent	Server	Mean	Error	StdDev	Median	Gen 0	Gen 1	Gen 2	Allocated
WithoutHttpCompletionOption	Server	False	True	428.7 ms	72.57 ms	108.62 ms	428.8 ms	-	-	-	389.94 KB
WithHttpCompletionOption	Server	False	True	483.2 ms	54.60 ms	81.72 ms	516.0 ms	-	-	-	146.13 KB
WithGetStreamAsync	Server	False	True	458.3 ms	63.28 ms	94.72 ms	514.9 ms	-	-	-	146.64 KB
WithoutHttpCompletionOption	ServerConcurrent	True	True	519.6 ms	12.83 ms	17.98 ms	515.4 ms	-	-	-	381.52 KB
WithHttpCompletionOption	ServerConcurrent	True	True	354.8 ms	50.80 ms	72.85 ms	327.6 ms	-	-	-	145.77 KB
WithGetStreamAsync	ServerConcurrent	True	True	490.3 ms	75.63 ms	110.86 ms	516.2 ms	-	-	-	148.85 KB
WithoutHttpCompletionOption	Workstation	False	False	484.2 ms	57.89 ms	83.03 ms	513.9 ms	-	-	-	307.69 KB
WithHttpCompletionOption	Workstation	False	False	432.8 ms	75.27 ms	105.52 ms	508.2 ms	-	-	-	146.98 KB
WithGetStreamAsync	Workstation	False	False	580.9 ms	60.71 ms	87.07 ms	534.8 ms	-	-	-	148.18 KB
WithoutHttpCompletionOption	WorkstationConcurrent	True	False	544.1 ms	61.84 ms	90.64 ms	530.3 ms	-	-	-	307.95 KB
WithHttpCompletionOption	WorkstationConcurrent	True	False	661.8 ms	94.76 ms	132.85 ms	710.2 ms	-	-	-	151.16 KB
WithGetStreamAsync	WorkstationConcurrent	True	False	565.5 ms	129.98 ms	182.21 ms	541.9 ms	-	-	-	143.86 KB

Exemplo

No mês de janeiro uma API começou a ter muitos problemas de estouro de memória, lembrando que essa aplicação está utilizando o plano B1 e não está sozinha no Service Plan. Olha como estava o consumo de memória na época:

Podemos notar que essa api consumia uns 280mb em média, mas teve um pico de 800mb. Depois de aplica essa otimização observe como está o consumo de memória um mês depois:

O consumo de memória não passa de 200mb. Já está rodando a alguns dias e não voltamos a ter problemas com essa API.

O que foi possível observar é uma considerável redução do consumo de memoria e uma aplicação mais estável no Service Plan B1.

Estudos futuros

Existem outras opções que posso alterar, mas como é um assunto bem complicado fica para uma publicação futura. Nem comentei quando estamos trabalhando em um ambiente de container (ex: docker), podemos definir um limite para a heap sem precisar altera o tipo de GC. Caso queriam saber mais, curte esse material:

Referencia

Vou deixar uma lista de conteúdo para você conhecer mais sobre o assunto.

.ltag__user__id__426430 .follow-action-button { background-color: #008000 !important; color: #dce9f3 !important; border-color: #008000 !important; }

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

HttpClient: melhoria de performance ao otimizar o uso de memória

Pode me chamar de Juscélio Reis — Thu, 04 Feb 2021 21:37:42 +0000

Neste último mês fiquei investigando incidentes relacionados a alto consumo de memória por parte das nossas aplicações. Consegui encontrar alguns problemas e quero compartilhar com vocês, vamos começar com a utilização do HttpClient, esse cara pode ser um vilão se não for bem utilizado. As APIs da Wiz têm uma característica de chamar outras APIs e me atrevo a dizer que é mais consumo de API do que utilização de banco de dados. Nesse artigo quero explicar como você pode otimizar o desempenho do HttpClient ao lidar com dados como cargas úteis JSON no HttpResponseMessage.

Teoria

O que eu não sabia era que por padrão, na maioria dos casos, ao usar HttpClient e seus metodos (GetAsync, PostAsync e SendAsync), todo o corpo da resposta é lido em um buffer de memória antes que o método seja concluído. Nesse ponto, a conexão TCP, usada para a solicitação fica inativa e estará disponível para reutilização para outra solicitação, um ponto aqui é que estou falando do dotnet core 3.1, se for falar do dotnet 5, existem opções melhores como é o caso da utilização do protocolo http2, aí a história é outra.

Na maioria dos casos esse comportamento é aceitável, já que evita o uso da conexão tcp pelo período mínimo de tempo necessário. Mas... em casos que não temos memória sobressalente, aí entramos no caminho infeliz da história pois essa abordagem padrão introduz alguma sobrecarga de memória. Já que a resposta da API, vou generalizar aqui, o JSON é armazenado em buffer usando um MemoryStream, podemos acessar esse buffer pela classe HttpResponseMessage. Dependendo do tamanho da carga de resposta, isso pode significar que armazenamos em buffer uma grande quantidade de dados na memória.

Solução

O que eu não sabia era que existe uma sobrecarga desses métodos esperando um enum HttpCompletionOption, esse enum possui 2 valores o padrão é o ResponseContentRead, esse aí informa para o HttpClient que é para ler o corpo do JSON e colocar em memória mesmo que a nossa aplicação não vai usar esse objeto, sim isso é possível. O segundo valor é o que iremos começar a utilizar aqui na Wiz chamado ResponseHeadersRead, esse cara indica para o HttpClient quando os cabeçalhos de resposta forem totalmente lidos. O corpo da resposta pode não ser totalmente recebido neste momento.

O principal benefício é o desempenho. Ao usar esta opção, evitamos o buffer MemoryStream intermediário, em vez de obter o conteúdo diretamente do fluxo exposto no Socket. Isso evita alocações desnecessárias, o que é uma meta em situações altamente otimizadas.

Aqui vai um exemplo, quero serializar uma lista de livros apenas quando receber um status code 200. Se eu receber um 500 vou lançar uma exception e não preciso do conteúdo da API que estou consumindo.

A forma de utilizar esse enum é bem simples, olha como fica:

_httpClient.GetAsync("http://openlibrary.org/search.json?q=tdd", HttpCompletionOption.ResponseHeadersRead);

O normal é analisar o conteúdo de alguma forma. Vou mostrar um código de como podemos escrever nossa chamada para isso.

using var response = await _httpClient.GetAsync("http://openlibrary.org/search.json?q=tdd", HttpCompletionOption.ResponseHeadersRead);

response.EnsureSuccessStatusCode();

if (response.Content is object)
{
      var stream = await response.Content.ReadAsStreamAsync();

      var data = await JsonSerializer.DeserializeAsync<Search>(stream);

      // do something with the data or return it
}

Usamos o EnsureSuccessStatusCode para garantir que o status code recebido é um 2xx. Em caso afirmativo, verificamos se há conteúdo disponível na resposta. Agora podemos acessar o fluxo do conteúdo de resposta usando ReadAsStreamAsync.

O problema dessa abordagem é que assumimos mais responsabilidade em relação aos recursos do sistema, uma vez que a conexão com o servidor remoto fica presa até decidirmos que terminaremos com o conteúdo. A maneira como sinalizamos isso é descartando o HttpResponseMessage, que então libera a conexão para ser usada para outras solicitações. Por isso não esquecer do using.

using var response = await _httpClient.GetAsync

Outra forma de garantir isso é usar o try/finaly, veja um exemplo:

var response = await _httpClient.GetAsync("http://openlibrary.org/search.json?q=tdd", HttpCompletionOption.ResponseHeadersRead);

response.EnsureSuccessStatusCode();

Search data = null;

try
{

      if (response.Content is object)
      {
            var stream = await response.Content.ReadAsStreamAsync();
            data = await JsonSerializer.DeserializeAsync<Search>(stream);
      }
}
finally
{
      response.Dispose();
}

if (data is object)
{
      // intensive and slow processing of books list. We don't want this to delay releasing the connection.
}

Estudo de caso

Fiz um programa de teste para ter um benchmark da performance do que citei nesse artigo. Essa analise é feita tanto no Windows como no Linux, usando o dotnet core 3.1. Vocês podem acessar aqui.

Observe a coluna Allocated, usando um sistema Windows com o método WithHttpCompletionOption chegamos a uma performance de 26,87% em comparação com WithoutHttpCompletionOption que representa 73,13% do consumo de memória.

Agora usando um sistema Linux com o método WithHttpCompletionOption chegamos a uma performance de 28,62% em comparação com o método WithoutHttpCompletionOption que representa 71,38% do consumo de memória.

Windows


BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
Intel Core i7-7500U CPU 2.70GHz (Kaby Lake), 1 CPU, 4 logical and 2 physical cores
.NET Core SDK=3.1.404
  [Host]           : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  Server           : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  ServerForce      : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  Workstation      : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT
  WorkstationForce : .NET Core 3.1.10 (CoreCLR 4.700.20.51601, CoreFX 4.700.20.51901), X64 RyuJIT

IterationCount=15  LaunchCount=2  WarmupCount=10

Method	Job	Force	Server	Mean	Error	StdDev	Median	Gen 0	Gen 1	Gen 2	Allocated
WithoutHttpCompletionOption	Server	False	True	477.6 ms	65.79 ms	96.43 ms	515.4 ms	-	-	-	404.48 KB
WithHttpCompletionOption	Server	False	True	673.4 ms	73.56 ms	103.12 ms	723.6 ms	-	-	-	162.16 KB
WithGetStreamAsync	Server	False	True	703.2 ms	149.15 ms	213.91 ms	662.3 ms	-	-	-	162.66 KB
WithoutHttpCompletionOption	ServerForce	True	True	414.7 ms	65.04 ms	93.27 ms	363.7 ms	-	-	-	394.98 KB
WithHttpCompletionOption	ServerForce	True	True	642.0 ms	81.61 ms	106.12 ms	642.8 ms	-	-	-	163.63 KB
WithGetStreamAsync	ServerForce	True	True	707.8 ms	97.39 ms	139.68 ms	727.4 ms	-	-	-	162.81 KB
WithoutHttpCompletionOption	Workstation	True	False	659.7 ms	96.77 ms	132.46 ms	643.2 ms	-	-	-	394.62 KB
WithHttpCompletionOption	Workstation	True	False	530.2 ms	9.43 ms	12.59 ms	528.1 ms	-	-	-	162.35 KB
WithGetStreamAsync	Workstation	True	False	439.2 ms	65.54 ms	98.10 ms	452.9 ms	-	-	-	161.59 KB
WithoutHttpCompletionOption	WorkstationForce	False	False	499.3 ms	52.65 ms	77.17 ms	517.6 ms	-	-	-	394.89 KB
WithHttpCompletionOption	WorkstationForce	False	False	626.4 ms	69.05 ms	94.52 ms	600.1 ms	-	-	-	162.98 KB
WithGetStreamAsync	WorkstationForce	False	False	508.5 ms	57.64 ms	82.67 ms	524.8 ms	-	-	-	162.39 KB

Linux


BenchmarkDotNet=v0.12.1, OS=ubuntu 20.04
Intel Core i7-7500U CPU 2.70GHz (Kaby Lake), 1 CPU, 2 logical cores and 1 physical core
.NET Core SDK=3.1.405
  [Host]           : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Server           : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  ServerForce      : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  Workstation      : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT
  WorkstationForce : .NET Core 3.1.11 (CoreCLR 4.700.20.56602, CoreFX 4.700.20.56604), X64 RyuJIT

IterationCount=15  LaunchCount=2  WarmupCount=10

Method	Job	Force	Server	Mean	Error	StdDev	Median	Gen 0	Gen 1	Gen 2	Allocated
WithoutHttpCompletionOption	Server	False	True	426.4 ms	73.53 ms	100.64 ms	409.1 ms	-	-	-	389120 B
WithHttpCompletionOption	Server	False	True	360.1 ms	53.91 ms	77.31 ms	331.1 ms	-	-	-	152472 B
WithGetStreamAsync	Server	False	True	328.8 ms	12.37 ms	17.74 ms	323.7 ms	-	-	-	149624 B
WithoutHttpCompletionOption	ServerForce	True	True	421.0 ms	71.88 ms	103.09 ms	426.8 ms	-	-	-	406960 B
WithHttpCompletionOption	ServerForce	True	True	515.3 ms	71.17 ms	104.32 ms	520.8 ms	-	-	-	149936 B
WithGetStreamAsync	ServerForce	True	True	525.4 ms	142.11 ms	203.81 ms	515.6 ms	-	-	-	150136 B
WithoutHttpCompletionOption	Workstation	True	False	NA	NA	NA	NA	-	-	-	-
WithHttpCompletionOption	Workstation	True	False	523.6 ms	94.41 ms	138.38 ms	515.3 ms	-	-	-	149520 B
WithGetStreamAsync	Workstation	True	False	582.9 ms	288.63 ms	404.62 ms	354.0 ms	-	-	-	150072 B
WithoutHttpCompletionOption	WorkstationForce	False	False	523.4 ms	44.34 ms	62.16 ms	527.0 ms	-	-	-	389112 B
WithHttpCompletionOption	WorkstationForce	False	False	523.0 ms	11.63 ms	16.68 ms	518.3 ms	-	-	-	150680 B
WithGetStreamAsync	WorkstationForce	False	False	427.7 ms	78.15 ms	104.33 ms	497.9 ms	-	-	-	151472 B

Pode me chamar de Juscélio ReisFollow

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

[Série] Governança de API: Contrato da API

Pode me chamar de Juscélio Reis — Wed, 05 Aug 2020 19:35:57 +0000

Recapitulando:

A área de governança precisa cruzar o anseio e desejos dos outros setores da empresa, com o objetivo de construir uma ponte entre o momento atual da empresa com o que pode acabar sendo uma futura estratégia de governança de API.

É clichê, mas resumindo fica assim: a área de governança busca alinhar a estratégia com a execução.

😒: Todo novo framework da moda tem essa frase. Como é possível esse alinhamento com a governança?

O monitoramento do desempenho passado é útil na avaliação de opções no momento presente, para determinar metas, políticas e ações futuras (direção). 😎

Aqueles que não conhecem a história estão fadados a repeti-la.
-- Edmund Burke

Como vai conseguir monitorar o passado se não sabe o que monitorar? No catalogo de API precisa existir no mínimo 4 informações, sendo elas o recurso, a estrutura, a capacidade e a sensibilidade. Logo ter um catalogo de API é o primeiro passo para o sucesso!

Para recapitular pode ir direto na fonte:

[Série] Governança de API

Pode me chamar de Juscélio Reis for DEVz Wiz ・ Jul 21 '20

#api #governance #development #devops

[Série] Governança de API: Centralização

Pode me chamar de Juscélio Reis for DEVz Wiz ・ Jul 28 '20

#api #governance #development #devops

O contrato da API: o primeiro e mais importante passo

Sem duvidas aqui é o ponto mais importante e mais complicado de ser feito, mas quando bem feito só temos ganhos. Para entender mais o motivo de começar com o contrato leia esse artigo:

Por que devemos começar nossas APIs pelo contrato?

Pode me chamar de Juscélio Reis ・ Jul 13 '20

#apidevelopment #openapi #apigovernance

Em um programa de desenvolvimento de API a primeira etapa é justamente a construção de um contrato. Com um contrato bem feito conseguimos automatizar rotinas, melhorar a experiência do desenvolvedor, permitir a independência dos times, acelerar a entrega das APIs para o mercado, melhora o entendimento das suas APIs, facilitar a rotina de testes 👻, gerar SDKs tanto para o cliente quanto para o servidor (ação automatizada é claro), possibilidade de ativar e desativar suas APIs e como não podia deixar de ser, monitorar o passado!

😒: o mundo real não é assim, ninguém para para criar contratos. O que o gestor quer é código em produção. Contrato, só se for contrato com um cliente pagante.

É uma visão bem comum, se você for direto para a criação de sua API, não haverá retorno ao design. É como construir uma casa e depois procurar um arquiteto para elaborar planos. Isso não faz nenhum sentido. 😎

No entanto, as equipes de software frequentemente fazem escolhas semelhantes. Eles podem gerar uma especificação de API a partir do código, o que parece eficiente. Infelizmente, quando você criou uma API no código, perdeu muitas das vantagens da abordagem do design primeiro. Quando o design da sua API existe antes da implementação, você pode obter feedback antecipado, conectar sua API às ferramentas desde o início e colaborar entre departamentos e funções. 😎

Colocar ordem no caos é uma tarefa árdua, ou exigir que desenvolvedores sigam um método que não seja o eXtreme Go Horse (XGH). Mas é necessário dar o primeiro passo. Assim também é implantar um programa de API, tenha em mente qual resultado deseja obter, e não foque no tamanho do percurso.

Suba o primeiro degrau com fé. Não é necessário que você veja toda a escada. Apenas dê o primeiro passo.
-- Martin Luther King

Você sabe quem usará sua API? Mesmo para um projeto interno, é provável que você tenha vários consumidores. Uma especificação de API permite que você compartilhe detalhes sobre como a API funcionará. Você pode enviar o documento de especificação em si ou usar ferramentas para criar um protótipo de sua API ou documentação. Você pode gerar servidores simulados com base em suas especificações, conforme descrito em outra seção, e fazer com que seus consumidores façam chamadas ao vivo.

Sua colaboração também pode ir além das equipes técnicas. Você pode obter ótimas informações sobre produtos, marketing, parcerias e muitas outras áreas da sua organização.

🙋‍♂️: Eu ouvi um amém irmãos?! 🙌🙌

O software raramente é construído inteiramente por desenvolvedores. Existem partes interessadas em toda a organização. E embora muitos desenvolvedores possam ter muita atenção ao produto, eles nem sempre têm a visibilidade da imagem completa. Se sua organização possui um grupo de produtos, é nesse ponto que a voz do cliente é mais ouvida. Envolva qualquer pessoa que entenda como uma API será usada nas discussões ao criar a API.

Quando você entender como o software será usado, poderá projetá-lo melhor. O maior erro no design da API é tomar decisões com base em como o sistema funciona, e não no que os consumidores precisam oferecer suporte. Para projetar casos de uso, você precisa conversar com os consumidores ou, pelo menos, incluir aqueles que os conhecem melhor.

Uma sugestão de ferramenta que faz muito bem esse papel e para melhorar seu dia é gratuita Stoplight Studio

stoplightio / studio

The modern editor for API Design and Technical Writing.

Stoplight Studio

Studio is Stoplight's next generation application for API design, modeling, and technical writing. A primary goal of Studio is to enrich, not replace, your existing workflows. When running locally it works fully offline, with folders and files on your computer just like your favorite IDE. When running in the browser, the web-native Git support allows you to effortlessly work with your existing repositories safely and efficiently.

Documentation

To learn more about Studio and the Stoplight platform, see our Platform Documentation.

Features

Full Support for OpenAPI v2 and v3

Studio comes with full support for the OpenAPI versions 2 and 3 specification formats for all functionality. That means full validation, mocking, and modeling support for both versions of the OpenAPI specification.

Graphical API Design

Form-based designing means you don't need to be an OpenAPI expert to get started. Studio has a "write" (code) mode with full OpenAPI autocomplete…

View on GitHub

Para gerar um mock desse contrato criado pelo Stoplight Studio é possível usar Prism na linha de comando e entregar esse mock para o dev front-end.

stoplightio / prism

Turn any OpenAPI2/3 and Postman Collection file into an API server with mocking, transformations and validations.

Prism Overview

Prism is a set of packages for API mocking and contract testing with OpenAPI v2 (formerly known as Swagger) and OpenAPI v3.x.

Prism provides:

Mock Servers: Life-like mock servers from any API specification document.
Validation Proxy: Contract Testing for API consumers and developers.
Comprehensive API Specification Support: OpenAPI v3.1, OpenAPI v3.0, OpenAPI v2.0 (formerly Swagger) and Postman Collections.

Ways to Use Prism

Hosted Prism

Stoplight provides hosted mock servers for convenience so that API consumers can experiment with an API without the need for backend code.

Use one of these options for instant, hosted mock servers:

Stoplight Platform: Collaborative API Design Platform for designing, developing and documenting APIs with hosted mocking powered by Prism.
Stoplight Studio: Free visual OpenAPI designer that comes integrated with mocking powered by Prism.

Learn more in the hosted Prism documentation.

Self-hosted Prism

Prism is an open-source…

View on GitHub

🧙: Já temos o contrato e o mock da API, que tal criar um código de API para rodar no servidor usando 1 linha de comando? Te apresento meu amigo, Openapi Generator

😒: Da onde ele veio?

🧙: Do github

😒: O que ele faz?

🧙: Gera SDK, código do desenvolvedor e documenta tudo. O melhor amigo do Dev SAGAZ.

OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)

OpenAPI Generator

Master (7.10.0)

⭐⭐⭐ If you would like to contribute, please refer to guidelines and a list of open tasks. ⭐⭐⭐

‼️ To migrate from Swagger Codegen to OpenAPI Generator, please refer to the migration guide ‼️

📔 For more information, please refer to the Wiki page and FAQ 📔

📔 The eBook A Beginner's Guide to Code Generation for REST APIs is a good starting point for beginners 📔

⚠️ If the OpenAPI spec, templates or any input (e.g. options, environment variables) is obtained from an untrusted source or environment, please make sure you've reviewed these inputs before using OpenAPI Generator to generate the API client, server stub or documentation to avoid potential security issues (e.g. code injection). For security vulnerabilities, please contact team@openapitools.org. ⚠️

‼️ Both "OpenAPI Tools" (https://OpenAPITools.org - the parent organization of OpenAPI Generator) and "OpenAPI Generator" are not…

View on GitHub

CLIENT generators

ada
android
apex
bash
c
clojure
cpp-qt5-client
cpp-restsdk
cpp-tizen
cpp-ue4 (beta)
csharp
csharp-dotnet2 (deprecated)
csharp-netcore
dart
dart-dio
dart-jaguar
eiffel
elixir
elm
erlang-client
erlang-proper
flash
go
go-experimental (experimental)
groovy
haskell-http-client
java
javascript
javascript-apollo (beta)
javascript-closure-angular
javascript-flowtyped
jaxrs-cxf-client
jmeter
k6 (beta)
kotlin
lua (beta)
nim (beta)
objc
ocaml
perl
php
powershell (beta)
python
python-experimental (experimental)
r
ruby
rust
scala-akka
scala-gatling
scala-httpclient-deprecated (deprecated)
scala-sttp (beta)
scalaz
swift4-deprecated (deprecated)
swift5 (beta)
typescript (experimental)
typescript-angular
typescript-angularjs-deprecated (deprecated)
typescript-aurelia
typescript-axios
typescript-fetch
typescript-inversify
typescript-jquery
typescript-node
typescript-redux-query
typescript-rxjs

SERVER generators

ada-server
aspnetcore
cpp-pistache-server
cpp-qt5-qhttpengine-server
cpp-restbed-server
csharp-nancyfx
erlang-server
fsharp-functions (beta)
fsharp-giraffe-server (beta)
go-gin-server
go-server
graphql-nodejs-express-server
haskell
java-inflector
java-msf4j
java-pkmst
java-play-framework
java-undertow-server
java-vertx
java-vertx-web (beta)
jaxrs-cxf
jaxrs-cxf-cdi
jaxrs-cxf-extended
jaxrs-jersey
jaxrs-resteasy
jaxrs-resteasy-eap
jaxrs-spec
kotlin-server
kotlin-spring
kotlin-vertx (beta)
nodejs-express-server (beta)
php-laravel
php-lumen
php-silex-deprecated (deprecated)
php-slim-deprecated (deprecated)
php-slim4
php-symfony
php-ze-ph
python-aiohttp
python-blueplanet
python-flask
ruby-on-rails
ruby-sinatra
rust-server
scala-akka-http-server (beta)
scala-finch
scala-lagom-server
scala-play-server
scalatra
spring

DOCUMENTATION generators

asciidoc
cwiki
dynamic-html
html
html2
markdown (beta)
openapi
openapi-yaml
plantuml (beta)

SCHEMA generators

avro-schema (beta)
mysql-schema

CONFIG generators

apache2
graphql-schema
protobuf-schema (beta)

Que tal dar o primeiro passo? Se esta na duvida olha essa musica que fizeram para quem não quis arriscar:

Introduçao
Centralização
Contrato da API
Diretrizes de estilo
Reutilização
Automação
Versionamento
Política de descontinuação
Rastreamento / Observabilidade
Descoberta de API

Referencial

Pode me chamar de Juscélio ReisFollow

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

[Série] Governança de API: Centralização

Pode me chamar de Juscélio Reis — Tue, 28 Jul 2020 02:19:30 +0000

Dando continuidade a nossa serie sobre Governança de API, vamos falar de Centralização. Quando queremos organizar a bagunça sempre lembro dessa fala do Deming:

Não se gerencia o que não se mede,
não se mede o que não se define,
não se define o que não se entende,
e não há sucesso no que não se gerencia
-- William Edwards Deming

Olhando atentamente essa fala, é possível inferir que para alcançar o sucesso é de extrema importância entender o contexto do problema e sua nuances. Não será diferente com o assunto desse artigo, afinal vivemos em um tempo complexo. A cada minuto que passa surge uma nova tecnologia, um novo serviço e uma nova forma de pensar, antigamente era mais simples, os sistemas eram todos construido para atender todas as necessidades, vulgo monolito, e todas as regras de negócios podiam ser extraídas de um único local. Atualmente estamos implementando microserviços, mesmo que não seja preciso leia mais sobre aqui. A quantidade de API ou serviços no meio corporativo só tem aumentado. Imagina quando começar a ser tudo (serverless)[https://aws.amazon.com/pt/serverless/] 🤪.

Sem levantar as nuances de certos contextos bem específicos do seu sistema. A forma mais simples pra iniciar o processo de entendimento do seu ambiente é criar uma lista com todas as APIs internas e externas. Informando uma breve descrição sobre características chaves para que qualquer ser humano consiga entender qual a utilidade e quando precisa consumir sua API. Essa descrição deve conter pelo menos os campos abaixo:

Recurso: descreve o motivo dessa API ter sido projetada, e o que ela consegue entregar, usando uma linguagem que os seres humanos, leigos, possam digerir;
Estrutura: uma descrição esquemática das APIs, incluindo URIs, estruturas de dados, segurança, etc. Podemos citar como exemplo aqui o OpenAPI;
Capacidade: qual a quantidade de requisições que essa api deve suportar, quantas requisições seu cliente já consumiu;
Sensibilidade: a API consome ou expõe dados que possam estar sujeitos a restrições regulatórias ou de privacidade, como dados de cartão de pagamento, dados de identificação pessoal e assim por diante.

Para tal inventario é dado o nome de Catalogo de API (vou usar esse termo daqui pra frente) ou Registro de API. Como exemplo de catalogo de API bem feito cito o ProgrammableWeb e o RapidAPI como exemplo a ser copiado.

O catalogo de API também ajuda a equipe de governança a criar e aplicar políticas. Existem alguns modelos para a construção dessa equipe, todos com o intuito de chegar no estado da arte em Governança de API.

Centralizado: Toda alteração arquitetural, desde a implementação de novos recursos até a aplicação ou introdução de novos elementos no cenário arquitetônico, sempre são revisadas e aprovadas por uma equipe centralizada. Esse modelo tem um grande problema de escalabilidade, já que isso pode fazer com que a equipe se torne um gargalo devido ao alto nível de demandas impostas a elas.
Descentralizado: Similar ao modelo anterior, mas formado por mais de uma equipe, menor, e essa possuindo autonomia para avaliar e validar certos aspectos da arquitetura, seja para um aplicativo específico ou para um conjunto de aplicativos relacionados. Agora o problema desse modelo é coordenar essas equipes, evitando que mudanças de uma equipe afete a outra equipe.
Distribuído: Formado por equipes especialistas em um conjunto de produtos e, portanto, responsáveis por eles. O conhecimento comercial e os aspectos de governança são cruciais para garantir que os controles corretos estejam em vigor.

Aqui eu indico o vídeo da Sensedia com o tema Repensando a Governança de APIs

Tenha um certo cuidado ao escolher o melhor modelo para sua organização. Como foi falado no post anterior, comece devagar e vai adaptando a sua realidade, reforçando as boas práticas e mudando o que não deu certo para o seu contexto.

Tome cuidado para não confundir catalogo de API com o portal do desenvolvedor, sob a ótica da governança todas as APIs são importantes, se é interna ou externa, ela deve estar no inventario. E o acesso a esse inventario deve ser divulgado para toda a empresa, principalmente para a área de negócio. Eles podem visualizar o que já existem e definir uma estratégia para consumir essas APIs de acordo com suas necessidades.

Mas um portal do desenvolvedor pode ser um produto, e como produto precisamos entender qual o seu publico alvo. Aqui é possível distinguir 3 tipos de publico alvo que uma organização geralmente possui:

Equipes internas: O objetivo inicial é permitir que suas equipes internas criem novas funcionalidades e aplicativos sobre suas APIs. Ao pensar no catalogo de API para equipes internas é importante pensar como que essas equipes vão consumir suas APIs, a experiência do desenvolvedor aqui é muito importante para ganhar escala.

The Wiz way to build technological solutions

Lucas Mindêllo ・ Jul 7 '20 ・ 3 min read

#microservices #governance #agile #devops
Parceiros e/ou Clientes: Seus parceiros de negócios e clientes são as próximas partes interessadas que podem fornecer mais valor agregado a sua organização por meio de APIs. A API do seu parceiro pode integrar-se ao aplicativo de RH de um cliente para otimizar as informações dos funcionários ou fornecer um benefício diferenciado para o seu cliente.
Desenvolvedores de terceiros: A etapa final é disponibilizar suas APIs para o público em geral e monetizar com isso 🤑. Se ainda não parou para pensar em ganhar dinheiro. Gaste um tempo e o explore esses sites aqui ProgrammableWeb e o RapidAPI.

Mantendo a inovação constante

É possível manter um fluxo de inovação constante, e apoiar a estratégia da sua organização? Para chegar nesse nível de maturidade é fundamental oferecer sustentação para tipo de público alvo, e manter uma alta taxa de inovação nesses portais, talvez até uma equipe dedicada exclusivamente na entrega dessas inovações.

Construir esses portais ajudam a entregar diferencial para os desenvolvedores que procuram APIs com o intuito de agregar valor no seu produto. A inovação e o diferencial desse produto aparece em como você pensa na forma que seu publico vai solicitar acesso, gerar suas chaves de API ou tokens OAuth. Como o desenvolvedor vai consumir sua API se será através de um contrato como Swagger ou usando um SDK feito por você.

Não fique preso apenas no inventario para o catalogo de APIs. Pense em como será a experiência do desenvolvedor, como esse produto vai ajudar nas entregas do dia a dia desse desenvolvedor. Só uma sugestão, é possível disponibilizar SDKs para qualquer tipo de linguagem de programação, um canal de ajuda, suporte, informações dos logs de alterações, mudança de contrato ou quando essa API vai deixar de ser suportada pela organização.

Agora que possui essas informações centralizadas é possível realizar uma analise do impacto de uma determina alteração, visualizar as dependências de cada API e conseguir enxergar a como estão sendo expostos os campos mais sensíveis. Existem ferramentas como o Stoplight, que entrega de uma forma visual essas visualizações. Para conseguir extrair o máximo dessas ferramentas será preciso entender o conceito de Contrato da API, e este é o assunto do próximo artigo dessa serie.

Introduçao
Centralização
Contrato da API
Diretrizes de estilo
Reutilização
Automação
Versionamento
Política de descontinuação
Rastreamento / Observabilidade
Descoberta de API

Referencial

.ltag__user__id__426430 .follow-action-button { background-color: #008000 !important; color: #dce9f3 !important; border-color: #008000 !important; }

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

[Série] Governança de API

Pode me chamar de Juscélio Reis — Tue, 21 Jul 2020 01:30:42 +0000

Nos últimos meses tenho notado um aumento substancial da utilização do termo API. Empresas estão cada dia mais criando e consumindo APIs e a procura por desenvolvedores que sabem construir APIs também tem crescido. Existem inúmeras maneiras de construir e fornecer uma API, para isso podemos citar grandes empresas que possuem soluções prontas e de alto custo visando entregar uma API no menor tempo possível, ou podemos construir do zero a um baixo custo nossas próprias soluções e entregar uma API gastando um tempo razoável.

Mas a maioria dessas soluções não são capazes de entregar um recurso fundamental: Gerenciamento do Ciclo de vida do desenvolvimento. Um desenvolvedor passa algum tempo criando APIs úteis e robustas, mas acaba lutando com a evolução orgânica do seu código e com as mudanças que o meio negocial pode impor no desenvolvimento, como a famosa frase: precisamos dessa alteração para amanhã. Será se esse desenvolvedor é capaz de informa qual o verdadeiro impacto que uma simples mudança de parâmetro pode trazer para todos os clientes?

👾🎤 Isso não faz sentido, o que mais existe por ai são ferramentas de ALM, DevOps ou acompanhamento de projeto.
-- Leitor ansioso

Para esses leitores, só posso responder que continuem lendo. E que o foco desse artigo é Governança de APIs. E por ser um tema bem especifico, precisamos de ferramentas bem especificas. É diferente do que construir um software que vai rodar apenas no navegador ou no desktop. Deixa apresentar como é a construção de uma API sem o gerenciamento do ciclo de vida do desenvolvimento.

Para as empresas cuja a estratégia de negócio tem como objetivo entregar API para um mercado em potencial, a governança é uma necessidade. Não sabe do que estou falando sugiro que naveguem no site ProgrammableWeb ou procure pelos temas Open Banking ou Open Insurance.

Atividades da governança de API

Foi falado um monte sobre governança de API e gerenciamento do ciclo de vida do desenvolvimento focando na entra de API. Mas afinal o que seria isso, quais são as atividades que diferenciam de uma construção de software para web ou desktop.

Primeiro preciso fazer uma pergunta a você; você sabe onde estão todas as APIs da sua empresa? Nesse exato momento consegue informar quais clientes estão consumindo suas APIs?

Nesse momento consigo definir a Governança de API como a disciplina que vai desenvolver um trabalho para entender onde as pessoas estão, ferramentas, serviços, habilidades, melhores e piores práticas. E cruzar com o anseio e desejos dos outros setores da empresa, com o objetivo de construir uma ponte entre o momento atual da empresa com o que pode acabar sendo uma futura estratégia de governança de API.

De nada adianta implantar uma solução completa e robusta que já foi validada em outros times, se não trabalhar pessoas, ferramentas, processos e cultura dos envolvidos.

A cultura come a estratégia no café da manhã
-- Peter Drucker

A governança é especialmente benéfica para organizações que possuem um trabalho de construção de API ou arquiteturas de microsserviços, entregando consistência dos seus serviços para toda a organização. Além de ajudar a evitar problemas como código duplicado, acoplamento rígido entre componentes, falta de confiabilidade e economia.

Afinal o desejo de quem trabalha no time de governança é que as pessoas se importem com o design da API e estejam abertas a aprender como outras pessoas estão projetando suas APIs. E que os próprio time consiga defender o valor que um bom projeto pode agregar ao negocio em vez de simplesmente responder um ticket do JIRA. Pois o ticket não diz nada sobre a API ser bem projetada e consistente com outras equipes, a governança entre aqui.

Esse foi apenas o primeiro artigo da serie sobre Governança de API. Para os próximos episódios vamos abordar os seguintes temas com a visão da governança.

Introdução
Centralização
Contrato da API
Diretrizes de estilo
Reutilização
Automação
Versionamento
Política de descontinuação
Rastreamento / Observabilidade
Descoberta de API

Referencial

.ltag__user__id__426430 .follow-action-button { background-color: #008000 !important; color: #dce9f3 !important; border-color: #008000 !important; }

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

App Configuration: um mundo entre configurações de ambiente e feature flags

Pode me chamar de Juscélio Reis — Thu, 23 Apr 2020 01:28:38 +0000

Feature Flags, ou Feature toggles, é uma técnica de desenvolvimento de software em que consiste na modificação de comportamento do sistema sem alterar o código fonte da mesma.

Qual o preço para usar essa maravilhosa técnica?

Simples, aumento na complexidade do desenvolvimento da aplicação.

Mas calma, podemos usar esse recurso maneira inteligente com o auxílio de ferramenta especializada, e essa ferramenta é o tema desse artigo Azure App Configuration.

App Configuration prover uma forma simples para que os desenvolvedores possam armazenar as configurações de suas aplicações, gerenciar as funcionalidades de sua aplicação. Sabe qual a parte mais incrível dessa ferramenta? É compatível com qualquer linguagem, existe bibliotecas para o .net core, .Net (Fullframework), Azure Function, Java Spring e outras através da api Rest.

Creio que para os desenvolvedores que não cansam de estudar, já ouviu falar em microserviço, e quem foi além nesse conteúdo deve ter em algum momento da vida esbarrado no termo Twelve-Factor App. Bom para quem não sabe o que é, segue uma breve descrição e qual a sua relação com o tema desse artigo:

Twelve-Factor App (aplicação doze-fatores) é uma metodologia para construir software como serviço. Indo mais além, para utilizar essa metodologia é necessário que a aplicação possua algumas características e sendo bem literal segue eles:

Utilizar de formatos declarativos para automatizar a configuração inicial, minimizar tempo e custo para novos desenvolvedores participarem do projeto;
Ter um contrato claro com o sistema operacional que o suporta, oferecendo portabilidade máxima entre ambientes que o executem;
São adequados para implantação em modernas plataformas em nuvem , evitando a necessidade por servidores e administração do sistema;
Minimizam a divergência entre desenvolvimento e produção, permitindo a implantação contínua para máxima agilidade;
E podem escalar sem significativas mudanças em ferramentas, arquiteturas, ou práticas de desenvolvimento.

Bom, não sou eu quem inventou essas características, é sério! Está escrito assim no site da metodologia. E como o nome da metodologia sugere existem 12 fatores para serem cuidadosamente elaborada nas suas aplicações. Somente se quiser ter um software como serviço, é claro 😜!

🗣 Até agora o autor desse artigo esta me fazendo de trouxa, pois fala, fala e não tem nada de App Configuration.

Leitor revoltado 😡

Sim, vou chegar lá! Só mais um pouco, preciso introduzir esse tema para. E somente aí, consigo explicar o real potencial do App Configuration e qual problema ela chegou para resolver! Vamos olhar os 12 Fatores.

Os Doze Fatores

I. Base de Código

Uma base de código com rastreamento utilizando controle de revisão, muitos deploys

II. Dependências

Declare e isole as dependências

III. Configurações 👈👈👈👈👈👈

Armazene as configurações no ambiente

IV. Serviços de Apoio

Trate os serviços de apoio, como recursos ligados

V. Construa, lance, execute 👈

Separe estritamente os builds e execute em estágios

VI. Processos

Execute a aplicação como um ou mais processos que não armazenam estado

VII. Vínculo de porta

Exporte serviços por ligação de porta

VIII. Concorrência

Dimensione por um modelo de processo

IX. Descartabilidade 👈

Maximizar a robustez com inicialização e desligamento rápido

X. Dev/prod semelhantes 👈

Mantenha o desenvolvimento, teste, produção o mais semelhante possível

XI. Logs

Trate logs como fluxo de eventos

XII. Processos de Admin

Executar tarefas de administração/gerenciamento como processos pontuais

Indiquei quais dos fatores esse serviço ajuda!!!! Se não concorda, comenta ai! A configuração de uma aplicação é algo bem comum e rotineiro no desenvolvimento, saber onde guardar o usuário e senha do banco de dados, configuração do servidor SMTP para envio de e-mail, ou até mesmo configuração do ClientId e ClientSecret dessa aplicação. Com isso, podemos dizer que existem de 2 a 3 ambientes com configurações distintas: Configuração de desenvolvimento, configuração de homologação e configuração de produção.

Existem várias formas de fazer isso, desde chapando essa configuração no código 🤦‍♀️🤦‍♂, criando 3 arquivos um para cada ambiente ou usando um serviço que centralize essas configurações, mas sendo remoto e com controle de acesso 👮‍♀️ 👮‍♂️! As duas primeiras tem o problema de versionar essas configurações em alguma ferramenta de controle de versão, podendo até mesmo informando certas credencias para pessoas que você não queria. A terceira forma, se você contou, e a última é o próprio App Configuration!!! 👇

Tenho uma configuração para cada ambiente, e na minha aplicação tem apenas uma referência para esse serviço! Podemos chamar essa referência de ConnectionString, um modo de somente leitura! Vejam um exemplo de configuração, outra relação bem interessante com a metodologia Twelve-Factor App é que eu consigo alterar uma determinada configuração e que essa alteração será refletida na aplicação.

🗣 Sem precisar reiniciar a aplicação?

Leitor curioso 🤓

Exatamente meu caro, não é necessário reiniciar sua aplicação para mudar valores como usuário e senha do banco de dados (quem nunca precisou fazer isso). Alterar a URL de um serviço. Posso até ter um serviço de configuração centralizado para várias aplicações, exemplo: Manter a URL do sistema de autenticação centralizada, evitando ter que alterar dezenas de serviço. Afinal, API em microserviço tende aos gremlins.

Cada bola verde é uma API

🗣 E qual a relação do App Configuration com o fator V. Construa, lance, execute? Não consigo ver nenhuma ligação.

Leitor revoltado 😡, ele continua lendo o artigo

Então, além de gerenciar as configurações existe outra funcionalidade bem interessante Feature Manager (em inglês pra ser chique 💁‍♀️ 💁‍♂️), consigo implementar uma forma de liberar novas versões do meu código para meus usuários/clientes apenas habilitando ou desabilitando um botão.

👈👈👈👈

Dessa forma posso implementar uma lógica, muito bem elaborada no meu software para caso eu habilite a feature beta, chama a parte X do meu software e caso essa feature está desligada chamo a parte Y do meu software.

De acordo com os meus cálculos1, quando a feature beta esta ligada o serviço GetAsync retorna a flag = Beta. E se a feature estiver desligada o retorno é a flag Não Beta.

🗣 Olhando as ilustrações vi que esta utilizando Microsoft.Percentage, pra que serve isso?

Leitor curioso 🤓

Boa!!!! Gostei de você caro leitor! Então, o Azure App Configuration consegue ter filtros, alguns já prontos como é o caso do Microsoft.Percentage. Esses filtros podem interferir na execução do seu código! Esse em especifico faz com que X% das minhas requisições executem o código com a feature beta habilitada e outros Y% executem sem a feature beta habilitada. E isso é ótimo!!!!

Podemos liberar nosso código para 10% dos nossos usuários, avaliar os erros e ir aumentando a porcentagem, limitado a 100% das requisições.

Vou compartilhar aqui o projeto onde eu configurei o Azure App Configuration, podemos conversar sobre. Olhem lá, podem copiar ou até mesmo criticar. 😝👻

https://github.com/juscelior/multitenant-core

🤑 E por hoje é isso galera!!! Não esqueçam de curtir (caso tenham gostado do artigo), clica em seguir para fortalecer a comunidade. Comente com o que achou. E não esqueça de compartilhar com seus coleguinhas do trabalho, bar, whatsapp, grupo da família…. 🤭

Podem ver outros artigos que escrevi aqui -> 🤞 https://medium.com/@juscelioreis 🤞

🤓😵 Referência desse artigo:

The Twelve-Factor App

Azure App Configuration best practices

Feature management overview

Azure App Configuration documentation

.ltag__user__id__426430 .follow-action-button { background-color: #008000 !important; color: #dce9f3 !important; border-color: #008000 !important; }

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

Por que devemos começar nossas APIs pelo contrato?

Pode me chamar de Juscélio Reis — Tue, 24 Mar 2020 01:56:24 +0000

Após uma década desenvolvendo software consigo afirmar o quanto é mais rápido construir código orientado a contrato (schema se preferir chamar assim). Porem nem sempre concordei com essa afirmação, na verdade faz pouco tempo que entendi qual o real ganho em trabalhar com essa abordagem.

Lembro de ter estudado no mestrado (como aluno especial) SOA (faz uns anos isso). Durante esse tempo o professor que seguia muito a metodologia que está nos livros do Thomas Erl, falava que para construir um serviço devemos começar pelo contrato. Nessa época eu discordava muito pois já trabalhava desenvolvendo serviços a muito tempo, entendia bem o WSDL e Web Services e suas especificações como WS-Basisc, WS-Trust, WS-* e REST, além de dominar uma tecnologia para construir serviços da Microsoft o famoso WCF (Adorava esse framework).

O que eu não entendia na época, mas entendo hoje, era que minha falta de bagagem, minha pouca experiência profissional e ficar isolado no mundo idealizado por um fornecedor de tecnologia, ignorando outros fornecedores além de não focar meus estudos ao conceito de serviços. Eu entendia que essa abordagem era pouco produtiva, provavelmente você caro leitor também ache isso.

O que eu não entendia na época era que para seguir uma abordagem orientada ao desenvolvimento ou melhor primeiro o código (code-first) é que corremos o risco de fazer um serviço especialista demais, dificultando o seu reaproveitamento ou no pior cenário imaginável uma alteração nesse serviço como uma mudança de um nome, exemplo: mudar Nmoe para Nome (afinal foi um erro de digitação), pode causar com que serviços consumidores quebrem, chegando ao ponto de sair do ar (serio, já vi isso acontecer com mais frequência que gostaria de confessar).

O que me fez mudar de ideia não foram somente os erros que pude presenciar, mas estudar o ser humano. É muito complicado para que desenvolvedores pensem de forma abstrata, evitando transpor as regras internas do serviço para a sua interface, pois tendemos a pensar de forma intuitiva e automática nesse contexto, levando a simplificações e replicações implícitas de padrões.

Podemos estar cegos para o óbvio e cegos também para a nossa cegueira

― Daniel Kahneman

O sistema intuitivo e automático em nossos cérebros é uma ferramenta poderosa e eficaz, mas às vezes é bom olhar para as coisas de outra perspectiva (Vuja De). Em vez de olhar o serviço sobre a perspectiva de código, vamos olhar primeiro para o seu contrato, sua interface e a partir dela abstrair o problema.

Para construir APIs precisamos de um ativo muito mais importante e complicado, pessoas!

Programação é uma atividade social.

― Robert C. Martin

Lembro das discussões da época, que programar usando SOAP (Simple Object Access Protocol) era obsoleto e muito pesado (não reflete minha opinião) e que o futuro era REST (Representational State Transfer). Esse último teve um crescimento incrível na comunidade de desenvolvimento de software. Porem nem tudo que vira padrão é o melhor, rs. Em REST não temos a cultura de pensar no contrato primeiro, para falar a verdade não existe uma especificação de contrato padrão. O mercado acabou adotando a especificação OpenAPI (OpenAPI Specification — OAS) como padrão é um dos mais adotados, mas saiba que existem outras especificações como RAML (RESTful API Modeling Language), WADL (Web Application Description Language).

Padrões como esses que citei acima, como o OpenAPI, ajudam a facilitar uma estratégia de desenvolvimento ‘design first’ ou ‘driven-definition’. Essa abordagem permite que as partes interessadas planejem uma API e sua funcionalidade antes de pensar em implementar o código. As próximas alterações e os requisitos de teste podem ser comunicados mais cedo, pois existe um plano para que todos possam trabalhar. Isso sim! É ganho de tempo, e acelera o desenvolvimento de fato. Existem outros benefícios, segue a lista abaixo:

Trabalhar orientando ao contrato é uma forma de manter o conhecimento, e olha que a cada dia fica mais complexo do desenvolvimento de software.
Ocultar a estrutura do banco de dados, além de diminuir a probabilidade de ter campos do banco expostos diretamente na interface do serviço. Melhorando e muito a segurança, e evitando problemas como alterar nome de um campo no banco ser obrigado a alterar o serviço.
Ao pensar nas entidades de domino, facilita a abstração, permite manobras internas do serviço o que pode contribuir com a resiliência de seu serviço.
É uma abordagem bem integrada com o TDD (Test Driven Design), melhorando o controle de qualidade da sua aplicação, pois ao alterar o contrato (Schema) e aplicar o teste de aceitação poderá pegar erros mais cedo no desenvolvimento.

O interessante é que essa abordagem ajuda na construção de uma governança em cima das APIs. Governança da API fornece uma abordagem orientada a políticas, impondo padrões e pontos de verificação ao longo do ciclo de vida da API ( olha que lindo isso aqui ).

A sua fronteira não fica isolada apenas no tempo de execução da API, mas também no design através de processos de desenvolvimento. Inclui as diretrizes, padrões e processos a serem seguidos para identificação da API, documentação da interface , desenvolvimento, teste , implantação, execução e operação. Os padrões e princípios definidos pela governança da API fornecem garantia de qualidade da API, como segurança, disponibilidade, escalabilidade e confiabilidade.

Governança

.ltag__user__id__426430 .follow-action-button { background-color: #008000 !important; color: #dce9f3 !important; border-color: #008000 !important; }

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

Framework para desenvolvimento de Bots: Computação cognitiva

Pode me chamar de Juscélio Reis — Fri, 27 Dec 2019 18:30:00 +0000

A computação cognitiva integra uma nova classe de problemas. Basicamente lida com situações complexas, ambíguas e incertas; em em outras palavras problemas humanos!

Esse artigo integra a série Framework para desenvolvimento de Bots. Mas agora vamos conversar sobre o que seria computação cognitiva, a parte inteligente que vai estar no seu software.

Framework para desenvolvimento de Bots:

Contexto.
Computação cognitiva.

Teoria

Antes de começar com exemplos e aplicações, precisamos definir um conceito comum sobre o que é computação cognitiva, o que mais observo são combinação de letras e siglas que está associada a inteligência artificial, mas nem todas estão ligadas a computação cognitiva. O conceito que vou apresentar não foi de minha autoria, foi de um consorcio de pessoas muito mais inteligentes e capaz para definir algo tão complexo e ao mesmo tempo maravilhoso! Então, senta que lá vem história:

Em meados de 2014 um grupo de especialistas, com formações bem eclética, de diversas instituições de ensino, além de grandes empresas de tecnologia resolveram sentar e tentar definir o que seria computação cognitiva e qual seria a sua diferença para outros tipos de inteligência artificial, porem era importante que esse termo não fosse proprietária, podendo ser utilizada como referência pela indústria de tecnologia da informação (TI), pesquisadores, mídias e seus usuários. Para mais informações podem acessar o site Cognitive Computing Consortium. Ou se preferir segue um resumo sobre inteligencia artificial feito para ajudar a entender o seu conceito, mais informação podem ler o artigo Demystifying Artificial Intelligence. What is Artificial Intelligence & explaining it from different dimensions.

Desmitificando a inteligencia artificial

Mas qual é a definição de cognitivo? Até agora só está me enrolando.

Cognitivo

Cog·ni·ti·vo 1. Que se refere à cognição ou ao conhecimento.

2. psicol Diz-se de estados ou processos que se relacionam à identificação de um conhecimento dedutível e à solução de tarefas e problemas específicos.

3. ling Que se refere ao processo mental de percepção, juízo, memória e raciocínio.

Definido computação cognitiva

Basicamente a computação cognitiva é caracterizada pela confusão; ops! Pelas situações complexas que são incertas e ambíguas. Meu exemplo favorito é a forma que mineiro fala, olha só:

Mineiro A pergunta ao mineiro B: Pó pô pó?

Mineiro B responde ao mineiro A: Pó pô.

https://medium.com/media/9e40d50d476983ee70391aa9337ca921/href

Como eu posso explicar a uma máquina que o primeiro Pó significa Pode e o segundo pó significa pó mesmo. Se até mesmo para alguns brasileiros, principalmente de outras regiões, não consegue entender esse exemplo, justamente por não conhecer o contexto por trás dessa expressão. Ou melhor, tenho outro exemplo formidável, a forma que minha esposa se expressa quando quer pedir para eu pegar alguma coisa.

Esposa: Pegue o trem do lado da coisa lá?

Eu: Pegar o que?

Esposa: Aquela coisa lá, com o trocinho coisado.

É um exemplo real. E sim faz sentido! Se não acredita veja esse vídeo aqui:

Agora como explicar a uma máquina, que no português temos várias formas de dizer a mesma coisa. Viu como esse tipo de situação é complexa, ambígua e incerta. Depende do contexto dos interlocutores envolvidos na conversa, e pode ainda sofrer mudanças, já que somos seres inteligentes e estamos sempre aprendendo novas habilidades.

Para responder à natureza fluida da compreensão dos problemas dos usuários, o sistema de computação cognitiva oferece uma síntese não apenas de fontes de informação, mas também de influências, contextos e ideias. Sendo assim esse sistema inteligente (cognitivo) deve responder com o que considera ser o melhor naquele momento, não o que seria o correto. Podemos afirmar aqui que não existe certo e errado, existe apenas eu acho! E sim, muitas pessoas estão aí se gabando que estão utilizando as tecnologias mais revolucionarias, mas que na raiz da solução estão pagando, ou construindo, sistemas para dizer o que acha com um grau de certeza!

A inteligência por trás dessa tecnologia está na forma que conseguimos organizar o caos, percorrendo coleções maciças de informações diversas para encontrar padrões e, em seguida, aplicam esses padrões para responder às necessidades do momento.

Um mundo globalizado como o nosso e que está cada vez mais conectado e ubíquo como o nosso. Precisamos rever a natureza dos relacionamentos entre pessoas e ambiente virtual, cada dia mais difuso onde tecnologias podem agir como um assistente, um treinador para o usuário ou podem atuar virtualmente autonomamente em muitas situações de solução de problemas, resultando em respostas indicativas, sugestiva, instrutiva ou simplesmente divertidas.

Para definir um sistema como cognitivo precisamos observar quatro características, sendo elas adaptativo, interativo, interativo e com estado e contextual.

Adaptativo

Sistemas cognitivos devem ser capaz de aprender com as mudanças, que os requisitos evoluem. Devem ser projetados para serem alimentados com dados dinâmicos e em tempo “quase” real.

Interativo

Devem ser simples para o usuário, deixando esses usuários confortáveis para dizer qual a sua necessidade. Os sistemas podem interagir com outros processadores, dispositivos e serviços em nuvem, bem como com pessoas.

Iterativo e com estado

Devem ajudar na solução de um problema, fazendo perguntas ou encontrando informações adicionais diretamente na fonte de dados. Eles precisam “lembrar” as interações anteriores e retornar informações adequadas para a aplicação específica naquele momento.

Contextual

Eles devem entender, identificar e extrair elementos contextuais, como significado, entidade, sintaxe, hora, local, domínio apropriado, regulamentos, perfil do usuário, processo, tarefa e objetivo. Eles podem recorrer a várias fontes de informação, incluindo informações digitais estruturadas e não estruturadas, bem como entradas sensoriais (visual, gestual, auditiva ou fornecida pelo sensor).

Os sistemas cognitivos coexistirão com os sistemas legados. Muitos sistemas cognitivos se basearão nos recursos de TI atuais. Mas a ambição e o alcance da computação cognitiva são fundamentalmente diferentes. Abandonando o modelo de computador como dispositivo, ele busca levar a computação a uma parceria fundamental mais próxima nos esforços humanos.

Os sistemas cognitivos diferem dos aplicativos de computação atuais, pois vão além da tabulação e cálculo com base em regras e programas pré-configurados. Embora sejam capazes de realizar tarefas da computação básica, eles também podem inferir e até raciocinar com base em objetivos mais amplos.

Para quem leu o primeiro artigo da serie um dos requisitos, não negociáveis, da nossa consultoria é implementar um bot conversacional utilizando o serviço da IBM o IBM Watson Assistant. Vamos entender o que seria esse tal de assistente vulgo bot. Seria um serviço de inteligencia com a finalidade ajudar sua marca a estar presente em qualquer dispositivo, aplicativo ou canal. Dessa forma o assistente pode se conectar aos recursos de engajamento do cliente que você já usa para entregar uma experiência de resolução de problemas unificada e envolvente para seus clientes, exemplo muito popular no Brasil seria o Whatsapp e Facebook.

Basicamente o assistente atual como um programa que interpreta a entrada do usuário, qualifica essa entrada para saber onde redirecionar o usuário e o que responder.

Teoria aplicada à prática

Agora vamos para a parte divertida, ou seja, vamos construir nosso assistente. Lembrando o nosso objetivo com essa parte pratica

Planejar um diálogo
Criando um assistente
Criando uma habilidade de dialogo (Dialog Skill)
Definir intents (intenções) customizados
Incluir uma entidade padrão e usá-la no diálogo para localizar padrões na entrada do usuário
Incluir entidades para tornar suas respostas mais específicas
Incluir nós de diálogo que podem manipular suas intenções
Juntando tudo em um diálogo

Planejar um diálogo

Antes de sair fazendo um bot conversacional é necessário ter mapeado o que deseja fazer. Em outras palavras precisamos de um serviço que ajude a criar um fluxo de conversa com início, meio e fim (é desejável que seja feito por um especialista, comumente chamado de UX Writer, já que é a parte mais complexa do desenvolvimento de um bot).

Particularmente gosto da ferramenta botsociety, pois possui uma camada de serviço gratuita. É excelente para demonstrar o bot antes de sair fazendo o fluxo na ferramenta da IBM. Uma das features que mais gosto é poder exportar um vídeo da a conversa:

Exemplo de um vídeo demonstrando como seria a conversa no whatsapp

Além de conseguir mapear fluxos alternativos e construir um fluxograma automaticamente de acordo com o que você for criando seu mockup, e possui ainda uma funcionalidade para realizar pesquisa e teste de usabilidade.

Fluxograma criado automaticamente

Exemplo da pesquisa de usabilidade

Criando um assistente

Uma vez que temos o fluxo mapeado vamos iniciar na o nosso assistente na plataforma da IBM. Se não possui uma conta é preciso criar uma conta:

O Watson Assistant (antigo Watson Conversation) é a API do Watson para a criação e desenvolvimento de interfaces conversacionais, ou chatbots. Este serviço possui uma interface simples e intuitiva para que profissionais não-técnicos possam usufruir de todos os recursos disponíveis, de forma simples e rápida.

IBM Developer Brasil

Crie sua conta da IBM Cloud. Feito isso vamos precisar criar nosso primeiro assistente, segue um vídeo para ajudar no processo de criação.

Criando um serviço Watson Assistant

Para criar um assistente precisamos procurar os serviços do watson, depois basta procurar pelo serviço Watson Assistant. Existe uma camada gratuita, com 10.000 mensagens recebidas de forma gratuita por mês. Este número somente é descontado através das chamadas de API. Além disso, é possível criar até 5 skills diferentes, com 100 intenções, 200 entidades e 100 nós de diálogo cada. No final da pagina é possível editar o nome do serviço. É possível utilizar o tutorial oficial da IBM (Criando um assistente).

Criando uma habilidade de dialogo (Dialog Skill)

Uma habilidade seria um conjunto de conhecimento em uma lógica treinada (baseada no cenário do seu negócio). É possível ter mais de uma habilidade para um assistente.

Um assistente é um conjunto de habilidades que podem ser agrupados em um único serviço para poder lidar com diversos cenários. No nosso caso é onde vamos criar o atendimento da secretaria da Escola do Futuro. E a habilidade que vamos construir seria a de um secretário.

Criando um assistente e uma habilidade

É possível utilizar o tutorial oficial da IBM (Criando uma habilidade de diálogo) também.

Definir intents (intençoes) customizados

Uma intent ou intenção representa o desejo do usuário, o que o usuário deseja quando está enviando uma mensagem. No caso do Watson Assistent existe um padrão de nomenclatura para intenções iniciando com #.

E para conseguir treinar essa intenção e indicar para o bot como faz para identificar a intenção do usuário, precisamos dar alguns exemplos. Exemplo:

Intenção: #sim

Exemplos:

sim

s

yeap

positivo

Como o exemplo acima é possível notar que existem diversas formas de dizer a mesma coisa (intenção), por isso é preciso treinar com exemplos, e com o tempo precisamos voltar nos exemplos e atualizar os mesmos.

Criando intenções customizadas

É possível utilizar o tutorial oficial da IBM (Definindo intenções) também.

Incluir uma entidade padrão e usá-la no diálogo para localizar padrões na entrada do usuário

Essas são entidades comuns criadas pela IBM que podem ser usadas em qualquer caso de uso. Eles estão prontos para uso assim que você os adicionar. É importante ressaltar que não é possível editar essas entidades.

Habilitando uma entidade pré definida

É possível utilizar o tutorial oficial da IBM (Criando entidades) também.

Incluir entidades para tornar suas respostas mais específicas

Entidades representam objetos da intenção, seria um valor que queremos retirar do meio da oração, ops mensagem que o usuário enviou.

Uma entidade possui um tipo, um valor e pode possuir um sinônimo ou um padrão. No caso abaixo estamos criando uma entidade contato com um valor CpfCnpj cujo padrão é um regex para identificar CPF (sim, sim, o cnpj ainda não está no exemplo abaixo).

Também é possível criar uma entidade cujo valor pode possuir sinônimos, como é o exemplo do menu. Nome da entidade menuUra, valor conhecerEscola, sinônimos: conhecer mais sobre a escola, conhecer escola, informação da escola. Qualquer um desses termos que o usuário escrever irá corresponder a entidade menuUra com o valor conhecerEscola.

Criando uma entidade personalizada

É possível utilizar o tutorial oficial da IBM (Criando entidades) também.

Juntando tudo em um diálogo

Agora que já foi criado as entidades e as intenções vamos juntar com o diálogo. Observe que um diálogo em branco sempre vai ter 2 caixas uma chamada Bem-vindo e outra Em outros casos, conforme imagem abaixo_._

Vamos começar criando um folder e dar o nome de Acolhimento, nesse exemplo esse folder serve para organizar tarefas relacionadas a etapa de acolhimento (receber o contato e identificar sua pessoa)

Criando o primeiro node

Dentro da pastar folder vamos criar nosso primeiro node (nó), esses 3 pontos na vertical tem a opção de criar o node. Esse node que estamos trabalhando vamos dar o nome de Boas-vindas, e vamos configurar para quando for identificado uma intenção de saudação vai ser direcionado para esse node. E como o watson vai saber disso? Simples basta configurar a caixa de diálogo logo abaixo da frase If assistant recognizes (se o assistente reconhecer) #saudacao (# lembra sempre intenções).

Agora podemos ter variáveis de contexto, criada para armazenar valores extraído da mensagem enviada pelo nosso usuário ou uma variável de controle interna. A sua sintaxe começa com $ como podemos ver abaixo criado no segundo node chamado Primeiro Contato !$contato (! representa negação $contato uma variável de contexto, e tudo junto indica que queremos entrar nesse node quando a variável $contato for nula ou não existir)

Logica para entrar no node.

Outro ponto não menos importante de um node é a forma que ele vai tratar no final da sua execução, podemos esperar que nosso usuário responda algo, ou podemos redirecionar para outro node. Para nosso exemplo o node Boas vindas, após imprimir a sua mensagem vai redirecionar para o node Primeiro contato, e caso sua condição seja verdadeira irá imprimir a sua mensagem.

Redirecionando para outro node.

Além de variáveis de contexto ou intenções podemos utilizar as nossas entidades para validar uma condição. Vamos olhar o exemplo de perguntar qual o CPF do nosso usuário, criamos um node para perguntar o CPF e esperamos que o usuário responda, em seguida criamos um node filho para validar se na mensagem enviada pelo usuário contém um CPF, se existir vamos armazenar esse valor em uma variável de contexto chamada $cpfContato.

Extrair valores de mensagem do usuário e salvando em variável de contexto.

Uma boa prática é perguntar se o que nosso usuário escreve está certo (não que isso aconteça com muita frequência!!), sendo assim vamos utilizar a variável que criamos $cpfContato e vamos utilizar como um valor para concatenar em uma mensagem que vamos enviar para esse usuário. E para saber se estamos no caminho certo vamos criar 3 nodes filhos da pergunta sendo um para tratar da intenção #sim, outro para a intenção #nao e uma para tratar qualquer mensagem que não foi reconhecida como #sim ou #nao.

Estrutura para confirmar uma informação

O interessante dessa abordagem é que não ficamos presos a valores literais, temos uma intenção logo tanto um valor sim como um yeap significa a mesma intenção. O mesmo vale para uma intenção negativa, serve tanto um não como um nops.

Após a etapa de acolhimento vamos mostrar nossa ura, ou se preferir chamar de menu com as opções que nosso usuário poderá solicitar um atendimento, é uma boa prática mostrar quais assuntos o seu bot consegue responder para seu usuário. Não deixe seu usuário perdido ou traumatizado em um bot sem um guia.

A nossa ura é inteligente o suficiente para entender expressões ou frases como reconhece um número. Lembra que criamos uma entidade chamada menuUra e para cada item dentro dessa entidade tínhamos um sinônimo vinculado a esse item. Então mesmo que o usuário escolha finalizar ou digite o número 4 vai cair no nó de finalização.

Exemplo de menu com múltiplas opções.

Esse artigo ficou maior do que o imaginado, deixo aqui o link para poder baixar a habilidade que criei nesse artigo e com isso ajudar você na sua jornada para a construção de um assistente virtual. Deixo também o link para o projeto que estou construindo durante o desenvolvimento dessa série de artigos.

juscelior/bot-template-community

.ltag__user__id__426430 .follow-action-button { background-color: #008000 !important; color: #dce9f3 !important; border-color: #008000 !important; }

Pode me chamar de Juscélio Reis

Professional in constant learning, software developer with almost 10 years of career, researcher on distributed systems and information security. Strong experience in software development with C #

Forem: Pode me chamar de Juscélio Reis

Integrações como estratégia para acelerar a colaboração no Open Insurance

O que queremos dizer com integração?

Open Insurance e a mentalidade de colaboração

Fluxos de trabalho unificados

Aprimorar a descoberta dos serviços

Reusabilidade

O Santo Graal da integração

Medir o desempenho dos produtos e serviços de software

Google DORA

Lead Time (Deploy Cycle Time)

Deployment Frequency

Mean Time to Restore

Change Fail Rate

Desempenho operacional (confiabilidade)

Relatório de 2022

Métricas depreciadas (tente não usar essas métricas)

Code Churn

Lines of Code

Divida técnica: O bureau de crédito da TI

O erro de 1 bilhão de dólares

Impactos da divida técnica

Por que isso acontece?

O papel da governança

TIC: por onde começar

O mercado de TIC

Opções para começar

Cursos rápidos

Cursos técnicos

Faculdade

Programas de bootcamp

GC: Otimizando para o ambiente do Azure

Azure

Garbage Collection

Otimização

Exemplo

Estudos futuros

Referencia

Pode me chamar de Juscélio Reis

HttpClient: melhoria de performance ao otimizar o uso de memória

Teoria

Solução

Estudo de caso

Windows

Linux

Pode me chamar de Juscélio ReisFollow

[Série] Governança de API: Contrato da API

Recapitulando:

[Série] Governança de API

Pode me chamar de Juscélio Reis for DEVz Wiz ・ Jul 21 '20

[Série] Governança de API: Centralização

Pode me chamar de Juscélio Reis for DEVz Wiz ・ Jul 28 '20

O contrato da API: o primeiro e mais importante passo

Por que devemos começar nossas APIs pelo contrato?

Pode me chamar de Juscélio Reis ・ Jul 13 '20

stoplightio / studio

The modern editor for API Design and Technical Writing.

Stoplight Studio

Documentation

Features

Full Support for OpenAPI v2 and v3

Graphical API Design

stoplightio / prism

Turn any OpenAPI2/3 and Postman Collection file into an API server with mocking, transformations and validations.

Prism Overview

Ways to Use Prism

Hosted Prism

Self-hosted Prism

OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)

OpenAPI Generator

CLIENT generators

SERVER generators

DOCUMENTATION generators

SCHEMA generators

CONFIG generators

Referencial

Pode me chamar de Juscélio ReisFollow

[Série] Governança de API: Centralização

The Wiz way to build technological solutions