DEV Community: Becomex

Cursor: um editor de código com IA integrada

vandrei de lima — Thu, 26 Jun 2025 19:13:22 +0000

Minha experiência com o Cursor: uma IDE com IA integrada

Com o objetivo de testar uma nova IDE, dediquei duas semanas para estudar e experimentar o Cursor, uma plataforma baseada no Visual Studio Code que se destaca pela sua integração nativa com inteligência artificial. Quis entender seu potencial para aumentar a produtividade e a eficiência no desenvolvimento de software. Durante esse período, utilizei a versão gratuita e a versão Pro em diferentes projetos.

No processo de desenvolvimento, alguns fatores contribuíram para uma boa performance e agilidade na entrega, como o entendimento completo das bibliotecas e frameworks utilizados, a visão holística do projeto e a compreensão dos requisitos das atividades. Tentei explorar a IDE ao máximo para identificar onde ela poderia facilitar e agilizar o processo de desenvolvimento. Neste artigo, explico primeiro as suas funcionalidades e, posteriormente, minha experiência prática com ela.

Primeiras impressões e tutorial inicial

Logo após o primeiro login, a IDE oferece a opção de importar configurações do VS Code — o que facilita bastante para quem já é familiarizado com aquele ambiente. A interface é praticamente idêntica à do VS Code, o que reduz muito a curva de aprendizado.

A instalação inicial é fluida e já conta com opções como terminal personalizado e sugestões inteligentes ativadas por padrão. Ela tem alguns modos de funcionamento como Agent, Ask e Manual.

Agent: a IDE irá conhecer a sua base de código de forma automática e poderá aplicar alterações em todo o seu código de acordo com as suas necessidades, é a forma mais recomendada de ser utilizada.
Ask: é a maneira convencional de se utilizar o Chat IA. Você consegue obter explicações e sugestões pelo chat sem que ele aplique alterações no seu código.
Manual: semelhante ao Agent, porém voltado para um escopo mais específico de alteração. A diferença é que não explora a sua base de código e nem executa comandos no terminal.

A IDE oferece um tutorial direto ao ponto, com atalhos que maximizam a interação com a IA:

Ctrl + K: interações com o código, como refatorações ou criação de funções.
Tab: sugestões inteligentes e autocompletar.
Ctrl + I: geração de estruturas como pastas e componentes.

Além disso, o painel lateral com o chat da IA fornece essas funções de forma interativa. As respostas são rápidas e mostram um entendimento surpreendente das tarefas, muitas vezes antecipando necessidades e oferecendo soluções antes mesmo de serem solicitadas. Claro que descrever o contexto com detalhes importantes ajuda a ter uma resposta mais precisa sobre a necessidade.

Recursos notáveis

Autocompletar inteligente

O recurso de autocompletar do Cursor se destaca por sua inteligência contextual avançada. Ao analisar o código existente e a estrutura do projeto, ele oferece sugestões precisas e contextualmente relevantes. A tecla Tab ativa essas sugestões, que vão desde completar funções e variáveis até gerar blocos de código inteiros baseados no padrão do projeto. O sistema aprende com seu estilo de codificação e se adapta, tornando o desenvolvimento mais fluido e eficiente. Infelizmente, na versão gratuita esse recurso tem limitações significativas de uso, o que pode impactar a experiência completa da ferramenta.

Aprimoramento com contexto

O chat da IDE possui um recurso poderoso de adição de contexto que potencializa significativamente as respostas da IA. Você pode enriquecer suas solicitações de várias formas:

Referências de código: incluir caminhos relativos de arquivos ou nomes de componentes/páginas específicas.
Documentação: anexar documentos técnicos ou especificações.
Referências visuais: adicionar imagens ou mockups para implementação.
Descrições detalhadas: fornecer explicações contextuais sobre o objetivo.

Quanto mais contexto você fornecer, mais precisas e alinhadas serão as sugestões e implementações geradas pela IA. O sistema é flexível, permitindo tanto referências diretas a arquivos quanto descrições verbais do que precisa ser modificado.

Modos de seleção da IA

O Cursor oferece diferentes IAs. Você pode selecioná-las manualmente ou deixar no modo automático e, conforme a sua necessidade, ele avalia qual seria a melhor para te atender.

Modo automático: ótimo para tarefas rotineiras.
Modo MAX: gera respostas mais completas e inteligentes, mas consome rapidamente os créditos da licença Pro.

Meus primeiros usos

Utilizei a IA em dois tipos de projetos: o primeiro iremos chamar de Projeto A, e o segundo, de Projeto B. No Projeto A, com uma interface já planejada e pronta no Figma, componentes e bibliotecas já estabelecidas, e regras de autenticação e permissões já definidas, testei a IA em um ambiente mais "engessado" para ver como ela poderia acelerar e melhorar as entregas. No Projeto B, foi um teste em um escopo aberto na criação de SAAS, onde dei mais liberdade e tentei acelerar o desenvolvimento.

No Projeto A

Após a criação manual do projeto a partir de um template básico com autenticação e configurações de deploy, iniciei a configuração do meu CSS, pedindo a instalação completa do Tailwind CSS. Após isso, expliquei para ela as páginas que eu utilizaria e, em seu contexto, sempre deixando claro as ferramentas que ela poderia utilizar, como Ant Design. Utilizei prints do Figma para ela inicializar os meus componentes. Nesse ponto, tive muita vantagem na organização do projeto, porém, por serem componentes complexos e customizados do Ant Design, consegui aproveitar cerca de 20% do que ela criou.

Para um uso eficiente da IA, ao realizar minhas perguntas, eu mencionava brevemente as ferramentas disponíveis no projeto e alguns componentes já criados para que ela utilizasse como exemplo. No chat, existe um campo para adicionar o contexto, que pode ser qualquer coisa, como um texto ou arquivo, mas o que mais utilizei foi inserir o caminho do local onde eu gostaria que ela aplicasse a alteração ou usasse como exemplo. O caminho pode ser passado diretamente no chat ou colocado nas opções de contexto. A IA consegue usar esses caminhos relativos para entender e gerar componentes com base em outros existentes.

Durante a reorganização de componentes, observei que alguns trechos foram quebrados — o que exigiu correções manuais. O próprio chat permite uma revisão das alterações que poderão ser aprovadas ou rejeitadas, isso facilitou muito a análise das suas implementações.

No Projeto A, ela se mostrou muito útil em atividades como criar e aplicar a tradução nas labels e campos, melhoria e organização do código, identificação de perda de memória ou problemas no ciclo de vida de execução, e melhoria na resolução de bugs e inconsistências. Seu autocompletar fez uma diferença significativa, não consegui mensurar com precisão, mas tive uma melhoria de 15% na velocidade das entregas apenas com o recurso de autocompletar.

No Projeto B

No Projeto B, criei um backend com NestJS apenas explicando o contexto do projeto e com um arquivo da estrutura da base de dados. Ela criou as APIs que solicitei, deixando tudo configurado e até mesmo uma integração com gateway de pagamento, onde tive apenas o trabalho de passar a chave da API. Pedi para que criasse um arquivo de documentação das APIs e dos detalhes de funcionamento. Exportei o chat e usei junto o arquivo de documentação no projeto front já pré-configurado. Pedi para que ela lesse o arquivo de documentação e sozinha criou as implementações de telas para cada API criada no backend, só tive o trabalho de validar o código implementado. Claro que nesse contexto dei a liberdade "artística" na interface e nos componentes. Tive um ganho de tempo super considerável usando-a nesse contexto.

Em resumo, testei sua capacidade de ler imagens e compreender códigos já implementados, com o objetivo de usá-los como referência para novas criações. Nesse processo, identifiquei algumas limitações, que podem ser atenuadas ao formular perguntas mais claras e direcionadas, além de fornecer links para artigos específicos e exemplos alinhados ao padrão de código existente.

Dicas de uso

O seu autocomplete (TAB) é muito poderoso, porém, para a versão gratuita acaba sendo bem limitado. Sugiro analisar bem cada uso para que otimize o que realmente seja vantajoso. Percebo que, em alguns casos, apenas conhecer os atalhos nativos da IDE já seria suficiente. No entanto, sua utilidade se destaca mesmo quando compreende o conceito por trás da lógica e consegue antecipar funções e implementações mais entensas.

Assim como a maioria das IAs, a forma com que geramos as perguntas melhora a entrega e reduz o gasto das requisições. Esclarecer para ela de forma direta e reduzida melhora bastante a performance das entregas. Aqui vão algumas dicas de como montar as suas perguntas:

Tarefa: esclarecer diretamente o que precisa ser feito.
Contexto: dizer brevemente as ferramentas e linguagens que estão sendo utilizadas, ou até o contexto de mercado.
Output: formato de saída, se seria apenas uma resposta simples ou alteração direta no código.
Exemplos: passar exemplos do próprio código, ou até mesmo recursos externos como links para aprendizado ou identificação do padrão de desenvolvimento.
Regras: definir regras para impedir que ela altere pontos críticos ou utilize algum padrão não desejado no desenvolvimento.

Usando esse padrão, consegui aproveitar melhor os tokens fornecidos gratuitamente e da versão Pro do Cursor.

Vale a pena a versão Pro?

A versão Pro custa US$20, cerca de R$118 na cotação da compra. Em testes, criei um CRUD do zero, sem especificações detalhadas de UI,e a IA reduziu em até 80% o esforço bruto. E, diferente da versão gratuita, o uso do autocomplete e das respostas mais complexas acaba não sendo tão limitado. Comparando com a versão gratuita, a maior diferença é perceptível no uso do autocomplete. Nas demais funcionalidades, com o modo "Max" também vemos uma compreensão melhor e respostas com uma qualidade superior.

Na minha experiência, a versão Pro realmente faz diferença para quem busca produtividade máxima e utiliza intensamente recursos de IA no dia a dia. O maior benefício está no desbloqueio do autocompletar inteligente e na liberdade para usar o modo Max sem se preocupar tanto com limites. Para quem trabalha com projetos grandes, precisa de respostas mais completas ou quer acelerar entregas, o investimento se paga rapidamente. No entanto, para usos mais pontuais ou para quem está começando, a versão gratuita já oferece um bom panorama das capacidades da ferramenta, permitindo avaliar se vale a pena migrar para o plano pago.

Nem tudo são flores

Apesar dos muitos pontos positivos, a ferramenta pode apresentar oscilações consideráveis na qualidade das entregas. Em alguns momentos, ela altera arquivos por conta própria, toma decisões inesperadas e até remove funcionalidades importantes, o que pode ser frustrante. No entanto, esses casos não são tão frequentes e, na maioria das vezes, o resultado é satisfatório. É importante sempre revisar as alterações sugeridas pela IA antes de aprová-las, garantindo que nada essencial seja perdido ou modificado indevidamente.

Conclusão

O Cursor se mostrou uma ferramenta poderosa para desenvolvedores que querem aliar produtividade e inteligência artificial no fluxo de trabalho. Sua integração nativa com IA, somada à interface familiar do VS Code, torna a adoção fácil e o ganho de eficiência perceptível desde os primeiros usos. O autocompletar inteligente, o chat contextual e a possibilidade de aplicar alterações diretamente no código são diferenciais que realmente impactam o dia a dia.

Apesar de algumas limitações na versão gratuita, principalmente no uso do autocompletar, a experiência geral é muito positiva. A versão Pro potencializa ainda mais esses ganhos, sendo indicada para quem deseja extrair o máximo da ferramenta. O segredo para aproveitar bem está em saber formular perguntas objetivas, fornecer contexto e explorar os recursos de automação oferecidos.

Recomendo o Cursor para quem já tem um bom conhecimento em programação, seja em projetos pessoais ou profissionais, e quer experimentar o futuro das IDEs com IA integrada. Não recomendo para iniciantes na programação, pois ele poderia até prejudicar seus conhecimentos caso seja usado de maneira inadequada no aprendizado.

🔗 Site oficial do Cursor

gRPC: um panorama do contexto histórico às aplicações práticas!

Mauricio Redmerski André — Sun, 20 Oct 2024 18:36:29 +0000

Olá, pessoal. Tudo bem?

Há algum tempo, desenvolvi um conteúdo sobre gRPC para criar um bootcamp e disseminar este conhecimento entre os times de software da Becomex. Embora o modelo de bootcamp não tenha sido implementado na prática, o material ficou excelente. Por isso, decidi transformar a parte teórica em um post e compartilhar esse conteúdo com a comunidade.

Para aprender qualquer coisa na vida, começar pelo básico é sempre uma ótima ideia. Antes de mergulharmos no gRPC, vamos entender o que é RPC e o caminho que nos trouxe até aqui. Neste artigo, você terá uma breve introdução aos conceitos de RPC, a diferença básica entre RPC e REST, e entenderá por que o gRPC é tão rápido e uma excelente alternativa para a transição de grandes volumes de dados. Além disso, vamos apresentar exemplos de implementação para facilitar o entendimento.
Então, ajeite-se na cadeira e prepare sua garrafa d'água, porque vem muita informação boa por aí!

A origem

O RPC ou Remote Procedure Call (chamada de processo remoto em português) é uma técnica que permite realizar a chamada de uma função de forma remota. Com o RPC, o recurso A solicita a execução de uma função ao recurso B, estes podem ser componentes distintos que compõem um grande circuito, ou computadores conectados em rede, mostrando que esse modelo de comunicação não está vinculado somente ao protocolo HTTP, mas também se aplicando facilmente a outros protocolos de comunicação.

As proposições teóricas de modelos de chamadas remotas em redes de computadores começaram a ser feitas na década de 70, tendo como marco importante a publicação da RFC 707 no final do ano de 1975 e no começo do ano de 1976 sob o título A High-Level Framework for Network-Based Resource Sharing. Esse documento, dentre outras coisas, enfatizou a necessidade de padronização dos protocolos de comunicação entre sistemas.

O primeiro uso comercial do modelo de comunicação RPC ocorreu em um projeto desenvolvido pela Xerox PARC em 1981. Foi durante esse período que o termo RPC teria sido cunhado por Bruce Jay Nelson, um dos cientistas da computação da empresa.

Anos mais tarde, o Google criou sua própria arquitetura RPC. Essa infraestrutura de propósito geral chamada Stubby foi utilizada por mais de uma década para conectar o vasto número de microsserviços operando dentro e entre seus data centers. Como afirmado pela própria Google, o Stubby possuía vários recursos excelentes, mas estava altamente acoplado à sua infraestrutura interna para ser considerado adequado para o lançamento ao público. Em 2015, a Google publica então o gRPC, um projeto de código aberto que nasce como a evolução do Stubby.

Ao contrário do que muitas pessoas podem pensar, o "g" em gRPC não significa Google. Na realidade, a cada nova versão lançada do gRPC, o "g" é ressignificado. Clique aqui e confira a lista de nomes atribuídos ao “g”. Para todos os efeitos, podemos entender o termo gRPC como high performance Remote Procedure Call ou chamada de processo remoto de alta performance no nosso bom português.

Diferença entre RPC e REST

O modelo REST Representational State Transfer é potencialmente o mais popular atualmente, e a maioria das APIs web com que trabalhamos são REST ou pseudo REST. Por isso, parece ser uma boa ideia explicar como o RPC funciona comparando-o a um modelo mais conhecido.

Fundamentalmente, o REST expõe os recursos ou entidades de sua aplicação e usa os métodos HTTP para fornecer significado semântico às ações realizadas. Já o RPC expõe as operações que a aplicação pode realizar e, em geral, usa apenas dois diferentes métodos HTTP (quando a comunicação se dá por esse protocolo).

Em uma API REST, se você desejar expor dados sobre usuários, você provavelmente teria o seguinte cenário:

GET api/v1/users
GET api/v1/users/:id
POST api/v1/users
PUT api/v1/users/:id
DELETE api/v1/users/:id

Em uma API RPC, ao invés de expor uma rota de usuários e usar os métodos HTTP para atribuir significado às operações, cada rota se parecerá como uma função específica. Veja o exemplo:

GET api/v1/getUserList
GET api/v1/getUserById
POST api/v1/createUser
POST api/v1/updateUser
POST api/v1/deleteUser

Cada modelo de comunicação oferece diferentes níveis de facilidade para representar as operações de uma aplicação. O REST, por exemplo, é ideal para operações de CRUD (criar, ler, atualizar, deletar), enquanto o RPC é mais eficiente para executar ações da sua aplicação, como enviar e-mails ou realizar cálculos. No entanto, nada impede que o RPC seja usado para operações de CRUD, assim como o REST pode ser aplicado para executar funções em uma API.

De onde vem o high performance do gRPC?

A essa altura, você já deve ter percebido que o gRPC nada mais é do que a implementação de um modelo de API RPC, construído de modo a fornecer um alto desempenho em suas execuções. Mas como esse alto desempenho é construído? A primeira coisa que precisamos entender é que o gRPC não é uma tecnologia em si, mas uma junção de várias técnicas e tecnologias. Bora explorar cada uma delas?

Execução sob o protocolo de comunicação HTTP/2

Implementar uma API gRPC significa utilizar o protocolo HTTP/2 para estabelecer a conexão e a troca de informação entre o cliente e o servidor. O HTTP/2 que também foi criado pelo Google oferece vários recursos de melhoria de desempenho em relação ao seu antecessor. Aqui, vamos explorar duas de suas principais características, mas você pode ter uma leitura completa consultando a RFC 7540.

Stream e Multiplexação

Uma das principais limitações do HTTP/1.1 é a sua restrição no envio e recebimento de dados. Nesta versão, não é possível enviar ou receber mais de uma mensagem por conexão, o que significa que, se você precisar enviar duas mensagens ao servidor, terá que abrir duas conexões separadas. Isso torna o processo mais lento, já que a cada requisição é necessário refazer o handshake com o servidor e reenviar eventuais informações repetitivas entre as requisições. Além disso, por questões de desempenho, o número de conexões simultâneas que um browser pode fazer com um servidor é limitado. Para entender melhor essa limitação, recomendo o artigo Why does your browser limit the number of concurrent network calls?.

O protocolo HTTP/2, por outro lado, permite algo chamado multiplexação, o que significa que é possível enviar mais de uma requisição ao servidor por meio de uma única conexão. Isso resolve as limitações de conexões simultâneas e os tempos de handshake que a versão anterior impunha. A imagem abaixo, retirada do livro HTTP/2 in Action, ilustra de forma simples esse funcionamento.

Compressão e redução dos headers

Outra característica interessante do HTTP/2 é a compressão dos headers das mensagens. Em alguns casos, os headers de uma requisição podem ser maiores que o próprio payload, e o HTTP/2 faz uma compressão eficiente dessas informações. Além disso, como essa versão mantém uma única conexão para várias solicitações, não é necessário reenviar todos os headers em cada requisição. O HTTP/2 apenas retransmite os headers que foram alterados e, para os que permanecem iguais, envia apenas um índice de referência.

Protocol Buffers

O Protocol Buffers (ou Protobuf, para os íntimos) é um método muito eficiente de serialização de dados. O Protobuf usa uma linguagem de definição de interface (IDL) para descrever arquivos agnósticos de plataformas e linguagens de programação. Esses arquivos contêm as especificações dos contratos e funções que o servidor pode fornecer e tanto o cliente quanto o servidor mantêm uma cópia desses arquivos, o que garante a coesão na troca de informações. Além disso, isso separa o contexto das mensagens trocadas na rede do seu conteúdo, diferentemente de contratos em JSON, onde contexto e conteúdo são enviados necessariamente juntos.

Veja o exemplo abaixo, que utiliza a IDL do Protobuf para descrever um contrato de um objeto que representa um produto, com as propriedades partnumber, que significam o código e a quantidade de um produto:

syntax = "proto3";

message Produto {
  string partnumber = 1;
  int32 quantidade = 2;
}

Na primeira linha, definimos a sintaxe "proto3". Na terceira, declaramos uma mensagem (ou objeto) chamada "Produto", que pode ser usada tanto como entrada quanto saída de uma função. As linhas quatro e cinco definem as propriedades desse objeto, indicando o tipo, nome e índice de cada uma. E aqui está o interessante: nós definimos índices que determinam a posição das propriedades, o que significa que a mensagem enviada via gRPC não precisa carregar o nome da propriedade, apenas seu índice.

Para ilustrar de forma mais clara, veja o exemplo em JSON que seria necessário para representar essa mensagem:

{
  "partnumber": "Boinas",
  "quantidade": 150
}

Cada caractere da mensagem acima precisa ser transmitido pela rede por meio físico do servidor até o cliente. Quanto maior a mensagem, mais tempo levará para ser transmitida. O Protobuf codifica essa mesma mensagem em um conjunto muito menor de dados, o que acelera a transmissão pela rede. A codificação dessa mensagem pelo Protobuf seria a seguinte: 0A06426F696E6173109601. Não se preocupe, vou explicar como chegamos a esse valor em breve 😉. E ainda, graças ao HTTP/2, esses dados serão comprimidos antes de serem transmitidos.

O Protobuf, que também foi criado pelo Google, pode ser usado de forma independente, sem estar necessariamente no contexto do gRPC. Se salvarmos o exemplo anterior em um arquivo chamado Produto.proto, podemos rodar o seguinte comando no terminal: echo 'partnumber: "boinas"; quantidade: 150' | protoc --encode=Produto produto.proto > produto.bin (você precisará instalar o protoc para isso). O comando echo indica que queremos imprimir um conteúdo, o texto entre aspas simples é o conteúdo que queremos imprimir, concatenamos essa impressão com a chamada do protoc indicando que queremos fazer o encode do objeto "Produto" --encode=Produto especificado dentro do arquivo produto.proto, por fim definimos que o resultado deve ser salvo dentro do arquivo produto.bin. Para visualizar arquivos com essa codificação, gosto de usar o VS Code com a extensão Hex Editor. É assim que você verá a sequência de caracteres 0A06426F696E6173109601 mencionada anteriormente.

O resultado gerado por essa operação é uma sequência hexadecimal, onde cada par de caracteres representa um conjunto de 8 bits. Vamos dar uma olhada mais detalhada nessa estrutura.

O primeiro bit de cada par é o most significant bit (MSB), ou continuation bit. Essa é uma estratégia inteligente de codificação para indicar se o próximo par faz parte da mesma representação de dado ou se é um dado separado. Quando o valor é 0, o par contém toda a informação. Se for 1, é necessário combinar os bits com o próximo par para interpretar o dado.

Os pares 0A e 10, destacados em vermelho na imagem, representam as definições das propriedades enviadas. Após o primeiro bit (MSB), os próximos 4 bits indicam o índice da propriedade (lembrando que no arquivo .proto definimos índices representados aqui), e os três bits seguintes destacados em negrito indicam o tipo da mensagem.

O par 06, destacado em azul, indica o comprimento da mensagem de texto (neste caso, 6 conjuntos), sempre que o tipo do dado for uma string, o dado será precedido por um ou mais conjuntos que definem o comprimento do texto transmitido na propriedade. Em seguida, destacado em cinza, temos a mensagem "Boinas", codificada.

Os últimos dois conjuntos, 96 e 01, representam o valor da propriedade "quantidade". Sabemos que devemos interpretar os dois pares juntos porque o primeiro par, 96, possui o valor 1 no MSB. Para interpretar um valor numérico serializado pelo Protobuf, removemos o MSB da sequência e aplicamos a técnica little-endian, ordenando os bits menos significativos à frente. Isso resulta na sequência 10010110, que representa o valor 150 que informamos em nossa mensagem de teste.

Se quiser entender mais sobre o processo de codificação do Protobuf, você pode consultar as especificações aqui.

Sintaxe e tipos padrões

Já vimos um pouco da sintaxe da IDL do Protobuf nos exemplos anteriores, mas vamos nos aprofundar em alguns conceitos básicos.

syntax = "proto3";

service DocumentoService {
  rpc List(ListDocumentoRequest) returns (stream ListDocumentoResponse);
}

message ListDocumentoRequest {
  reserved 3;
  int64 analise_id = 1;
  optional int32 tipo_documento = 2;
  optional string cnpj_participante = 4
}

message ListDocumentoResponse {
  Documento documento = 1;
}

message Documento {
  int64 documentoId = 1;
  string chave_eletronica = 2;
  bool valido = 3;
  string cnpj_emitente = 4;
  repeated Produto = 5;
}

message Produto {
  string partnumber = 1;
  doubel valor = 2;
}

No exemplo acima, usamos o termo service para indicar que estamos descrevendo as funções de um serviço chamado DocumentoService. Em seguida, usamos o termo rpc para descrever as funções que esse serviço suporta. Definimos uma função chamada List, que recebe um objeto ListDocumentoRequest e retorna um stream de dados chamado ListDocumentoResponse. O uso de stream indica que o volume de dados pode ser alto, permitindo que o cliente processe os dados de forma parcial conforme o servidor os envia.

Nosso exemplo continua com a definição da estrutura do objeto ListDocumentoRequest. Nele, especificamos que a posição de índice 3 é reserved, o que significa que nenhuma propriedade pode ocupar essa posição. A posição 3 não tem nada de especial, foi apenas uma escolha para demonstrar essa possibilidade. Também definimos uma propriedade chamada analise_id como int64, e as duas propriedades seguintes são marcadas com o termo optional. Isso significa que, ao transmitir a mensagem, podemos omitir esses dois parâmetros.

Um ponto importante a se observar ao definir propriedades como optional no Protobuf é que, ao fazer isso, habilitamos uma propriedade chamada Has{MinhaVariável} no objeto convertido para a nossa linguagem de programação. Antes de acessar a propriedade optional, é essencial verificar se essa propriedade está marcada como true ou false. Se tentarmos recuperar a propriedade diretamente, sem essa verificação, receberemos o valor padrão do tipo de dado em questão (0 para inteiros e vazio para strings por exemplo).

Veja um exemplo em C# de como recuperar esses dados:

private DocumentoFilter MapToFilter(ListDocumentoRequest request)
{
  return new DocumentoFilter()
  {
    AnaliseId = request.Query.AnaliseId,
    TipoDocumento = request.Query.HasTipoDocumento
      ? request.Query.TipoDocumento
      : null,
    CnpjParticipante = request.Query.CnpjParticipante
  };
}

Antes de acessar o parâmetro TipoDocumento, foi necessário verificar o estado da propriedade HasTipoDocumento. Se tivéssemos acessado TipoDocumento diretamente, o valor retornado seria zero. No caso de CnpjParticipante, podemos recuperar o valor diretamente, mesmo que seja opcional. Fazer isso não causará erro, o retorno será apenas uma string vazia. Se você precisar diferenciar entre strings vazias e valores nulos (quando o usuário não fornecer esse dado), deverá usar a propriedade HasCnpjParticipante, da mesma forma como fizemos com TipoDocumento.

Seguindo com a análise da sintaxe do arquivo .proto, temos a definição do objeto ListDocumentoResponse. Nesse objeto, há uma propriedade do tipo Documento, que é um objeto personalizado. No Protobuf, podemos encadear objetos livremente, e Documento possui uma propriedade do tipo Produto como exemplo. O termo repeated que precede o tipo Produto indica que essa propriedade é, na verdade, uma lista de produtos. Você pode consultar os tipos padrões e termos reservados da IDL do Protobuf aqui.

Um ponto importante a se observar quando estiver criando seus objetos. Caso sua entidade possua uma propriedade repeat que pode receber uma lista muito grande dados, convêm não inclui-la no retorno de sua entidade, ao invés disso, crie uma outra função que retorne essa lista e permita que seu cliente chame simultaneamente as rotas da entidade pai e de sua lista de propriedades, dessa forma o desempenho na operação dos serviços do gRPC será muito superior.

Também é possível criar enumeradores no Protobuf e passar parâmetros que aceitam valores nulos, o que elimina a necessidade do termo optional. Se quiser saber mais sobre isso, você pode consultar a documentação. Um conselho: se usar propriedades complexas que podem transmitir valores nulos, não use o termo optional, já que não faz sentido declarar optional em propriedades com tipos nullables.

Criando serviços gRPC

Finalmente chegamos à parte mais esperada: colocar a mão na massa! Para iniciar um projeto de servidor gRPC em C#, você pode usar o seguinte comando: dotnet new grpc -o NomeDoProjeto.

O resultado será um Program semelhante ao seguinte:

using GrpcDocumento.Services;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddGrpc();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.MapGrpcService<GreeterService>();
app.MapGet("/", () => "Communication with gRPC endpoints must be made through a gRPC client. To learn how to create a client, visit: https://go.microsoft.com/fwlink/?linkid=2086909");

app.Run();

A função MapGrpcService inclui os arquivos de Services que você criar, fornecendo os endpoints definidos nos arquivos .proto. Para começar, basta criar seus próprios arquivos .proto e compilar o projeto. O .NET gerará as classes e tipos necessários para que seu serviço herde a classe base gerada pela compilação do arquivo .proto. Um exemplo disso pode ser visto no template, onde o serviço GreeterService herda as implementações de Greeter.GreeterBase e implementa os métodos definidos para o RPC.

Com o conteúdo que vimos até agora, você já deve ser capaz de criar APIs gRPC simples. Então, vou pular para algo mais avançado e divertido: a criação de métodos que recebem e enviam streams de dados. Se você precisar de um passo a passo mais detalhado para a criação de servidores gRPC, pode acessar o tutorial: Criar um cliente e um servidor gRPC no ASP.NET Core disponibilizado pela Microsoft.

Vamos supor que você precise criar uma função que receba e envie um stream de dados. Um exemplo de implementação seria o seguinte:

public async override Task List(
  IAsyncStreamReader<ListDocumentoRequest> requestStream,
  IServerStreamWriter<ListDocumentoResponse> responseStream,
  ServerCallContext context)
{
  while (await requestStream.MoveNext())
  {
    var filter = MapToFilter(requestStream.Current);
    var documentoList = _documentoService.GetDocumentoList(filter);
    await foreach (var documento in documentoList)
    {
      await responseStream.WriteAsync(documento);
    }
  }
}

Quando o arquivo .proto define a entrada de dados como stream, o tipo recebido na função será IAsyncStreamReader<T>, onde T é o tipo de dado de entrada. Se o retorno da função for definido como stream, o tipo retornado será IServerStreamWriter<T>. No requestStream, você pode usar a função MoveNext para aguardar o próximo pacote de dados enviado pelo cliente ou processar o pacote já recebido. No responseStream, você pode usar a função WriteAsync para enviar pacotes de resposta ao cliente.

Se você está lidando com streams, provavelmente trabalhará com grandes volumes de dados. Nesse caso, é interessante realizar consultas paginadas no banco de dados, para otimizar a eficiência e reduzir o volume de dados em trânsito. Confira abaixo um exemplo de implementação para a função GetDocumentoList usada no exemplo anterior:

public async IAsyncEnumerable<DocumentoResponse> GetDocumentoList(DocumentoFilter)
{
  var documentoQuery = _repository.GetDocumentoQueryByFilter(filter).AsNoTracking();
  var skip = 0;
  var count = 0;

  do
  {
    count = 0;
    foreach (var documento in documentoQuery.Skip(skip).Take(1000))
    {
      count++;
      yield return MapToResponse(documento);
    }
    skip += 1000
  } while (count == 1000);
}

O código acima realiza consultas paginadas de 1000 em 1000 registros e processa os dados sob demanda, usando IAsyncEnumerable e yield return até que todos os dados compatíveis filtrados sejam retornados.

Um destaque importante ao criar servidores gRPC que retornam streams de dados é que os dados enviados para o client são armazenados em um buffer. Como esse buffer não é infinito, se você enviar dados mais rápido do que o client pode consumir, poderão ocorrer erros de estouro de buffer. Você pode ignorar esse problema e deixar que o client lide com o processamento, ou pode ser uma pessoa legal e implementar técnicas que evitem isso, como aguardar um sinal do client para enviar dados paginados sob demanda, de acordo com sua capacidade de processamento.

Consumindo uma API gRPC

Agora, suponha que você já tenha um projeto e deseja consumir uma API gRPC. O processo é bem simples. Primeiro, instale as seguintes bibliotecas:

Grpc.Net.Client
Google.Protobuf
Grpc.Tools

Em seguida, adicione o código necessário no arquivo csproj para mapear os arquivos .proto desejados:

<ItemGroup>
  <Protobut Includ="Protos\documento.proto" GrpcServices="Client" />
</ItemGroup>

Para saber mais sobre as estruturas e relacionamentos entre os nugets do gRPC e sua arquitetura, consulte o blog gRPC.

Agora vamos implementar a função que cria a conexão com o servidor e chama o endpoint RPC

public async Task CallDocumentoServiceAsync(IEnumerable<string> analiseIdList)
{
  using var channel = GrpcChannel.ForAddress("endereco_grpc");
  var client = new DocumentoServiceClient(channel);
  var duplexStream = client.List();

  await SendRequestMessageAsync(analiseIdList, duplexStream);
  await ReceiveResponseMessageAsync(duplexStream);
}

public async Task SendRequestMessage(
  IEnumerable<string> analiseIdList,
  AsyncDuplexStreamingCall<ListDocumentoRequest, ListDocumentoResponse> duplexStream)
{
  foreach (var analiseId in analiseIdList)
  {
    var grpcRequest = new ListDocumentoRequest
    {
      AnaliseId = analiseId
    };

    await duplexStream.RequestStream.WriteAsync(grpcRequest);
  }

  await duplexStream.RequestStream.CompleteAsync();
}

public async ReceiveResponseMessageAsync(
  AsyncDuplexStreamingCall<ListDocumentoRequest, ListDocumentoResponse> duplexStream)
{
  while (await duplexStream.ResponseStream.Move())
  {
    // TODO: Sua implementação
  }
}

A função acima cria um canal gRPC com o endereço do servidor especificado e usa o tipo DocumentoServiceClient gerado a partir da compilação do arquivo .proto para definir o serviço que será chamado. Em seguida, chamamos a função RPC List, que recebe e envia um stream de dados. O retorno da função é um duplexStream.

Em seguida, na função SendRequestMessage, fazemos o stream das requisições, escrevendo cada solicitação com await duplexStream.RequestStream.WriteAsync(grpcRequest);. Depois de enviar todos os pacotes, necessários, é importante informar ao servidor que finalizamos as requisições, chamando a função await duplexStream.RequestStream.CompleteAsync();.

Por fim, a função ReceiveResponseMessageAsync lida com o stream de retorno do servidor, percorrendo cada um dos retornos com duplexStream.ResponseStream.MoveNext() para processar os objetos retornados.

No exemplo fornecido, estamos enviando todas as requisições e, em seguida, recebendo todos os retornos. No entanto, a conexão gRPC é bidirecional, permitindo enviar e receber dados simultaneamente. Isso significa que poderíamos colocar cada função em uma thread separada, otimizando ainda mais o desempenho do envio e recebimento de dados entre cliente e servidor.

Caso você queira construir um servidor gRPC mas não queira criar um cliente apenas para testes, é possível usar o postman para consumir APIs gRPC, facilitando o teste das suas funções.

Conclusão e referências adicionais

O gRPC é uma ferramenta incrível para trafegar grandes volumes de dados, e há muitos cenários onde ele pode ser aplicado. Tenho certeza de que você poderá tirar grande proveito desse conhecimento.

Abaixo estão alguns links adicionais que você pode gostar:

https://blog.lsantos.dev/guia-grpc-1/

https://www.hipsters.tech/http2-magia-com-o-novo-protocolo/

Sua lógica, sua história: O que seu código diz sobre você

Mauricio Redmerski André — Mon, 08 Jan 2024 13:42:44 +0000

Olá, pessoal! Espero encontrar todos bem. Hoje você aprenderá que tipo de programador você é, qual é a história que os códigos que você escreve contam sobre você, e em qual gênero literário você seria encaixado se estivesse escrevendo um livro.

Escrever códigos de computadores é como escrever um livro, algumas estórias nos prendem, nos fazem querer saber mais sobre aquilo que está sendo contato, outras estórias nos repelem, e o único motivo para seguirmos lendo é a obrigação de saber o que acontece no final do livro, digo, final do código. Assim como escritores famosos, nós programadores temos cada um o seu próprio estilo, os seus próprios vícios, e marcamos nossas obras com nossa impressão digital ainda que não percebamos, e ainda que sigamos algum style guide.

As impressões digitais que deixamos para trás ao escrever um código de computador contam muito sobre nós mesmos, e mais ainda, a depender do nosso estilo, diria que nos permitem ser encaixados como produtores literários de livros que vão desde gêneros de romance, até gêneros de terror....

Há algum tempo, eu tive contato com um vídeo sobre React e ficção (link nas referências), no qual a palestrante traça um paralelo entre a escrita criativa de estórias de ficção, e a escrita de códigos de computadores. Inspirado por esse conteúdo, resolvi escrever esse artigo, e nele trato de forma ilusória as minhas próprias percepções sobre os códigos que leio, comparando-os com os sentimentos que se buscam despertar os diferentes gêneros literários.

**O autor adverte, qualquer semelhança com eventos reais, pessoas vivas ou mortas é mera coincidência 😁

Feito o preâmbulo, você está ansioso para saber o que o seu código conta sobre você? E qual é o gênero literário que você seria encaixado se o seu código fosse um livro?

Os gêneros literários dos programadores

Comecemos por definir alguns gêneros e algumas características nos códigos normalmente atribuíveis àqueles.

Terror

Todos nós em algum momento da vida já tivemos que lidar com algum código que nos assustou quando estávamos lendo, e que nos rendeu alguns pesadelos a noite. De fato, existem algumas coisas que são o terror dos programadores, confere só essa pequena lista e me diga se isso não te dá um frio na espinha:

Arquivos com o número de linhas intermináveis;
Linhas de código que poderiam dar a volta no planeta Terra;
O mesmo nome de variável sendo usada para várias coisas diferentes;
Todos os arquivos do projeto na pasta raiz do repositório;
Funções que passam como parâmetro a chamada de outras funções, que passam como parâmetros a chamada de outras funções, que passam como parâmetro a chamada de outras funções, que passam como parâmetro a chamada de outras funções.... Só para deixar claro, essa crítica não se aplica em linguagens funcionais 😁.

E por fim, e mais assustador, alguns programadores adoram esquartejar suas variáveis, muitas vezes, tudo que sobra para trás para contar história é um X marcando o local onde o ataque aconteceu.

lst.forEach(x => x.SOCORRO);

Suspense

Alguns códigos, quando precisamos debugá-los, nos dão a mesma experiência de ler um bom livro de suspense.

Os códigos que estou classificando aqui como suspense são aqueles que todas as vezes que executamos, não sabemos o que esperar, às vezes funciona, às vezes gera um erro, às vezes retorna um resultado, às vezes outro.

Isso costuma acontecer quando uma função faz várias coisas e possui vários efeitos colaterais, além de não deixar claro o que a mesma pretendia fazer.

function funcao1(objeto) {
  if ("o dia está ensolarado")
    console.log("bora curtir uma praia");
  if ("o vento está para o norte")
    objeto.propriedade = 1;
  if ("está chovendo")
    throw new Exception("O Dev pira");
}

Ficção

Ficção definitivamente é um gênero muito popular, pelo menos quando se trata de livros, quem nunca viu uma obra de Isaac Asimov? Quando falamos de algoritmos de computadores, esse gênero não é tão popular assim, é raro, mas acontece com frequência 😁.

Obras de ficção costumam brincar com a realidade, e desafiam o nosso conhecimento ou extrapolam teorias, nos algoritmos de computadores isso costuma ser visto quando o autor escreve uma função cujo objetivo do que se busca e do que se faz só pode ser ficcional.

function somarNumeros(int left, int right) {
  return left - right;
}

Romance

O amor é lindo, e mais lindo que o amor é um código escrito com paixão. Programadores experientes conseguem ver através do código e dizer com quanto carinho o código foi escrito pelo autor.

Poucas coisas são tão satisfatórias quanto trabalhar com um código que foi escrito com esmero, é possível sentir quando o programador se esforçou em tornar o seu trabalho entendível e lapidado. Ainda que não seja o melhor código possível, e não se trata disso! Um programador que escreve romances toma o cuidado de deixar as coisas onde se espera que elas estejam, e conduzem o leitor de seus códigos em uma valsa de funções e variáveis imitando o mais belo dos sonetos.

Escritores deste gênero tomam o cuidado de indentar seus códigos com um padrão bem estabelecido, ainda que o leitor prefira outras formatações, é notável que o autor se esforçou para manter tudo com a mesma estética, e não jogou simplesmente os elementos na tela como quem bate com a cabeça no teclado.

As revelações que os códigos fazem sobre seus autores

Tendo visto alguns gêneros literários usados para falar de características gerais dos desenvolvedores, daremos sequência observando algumas características mais pontuais, itens que os códigos revelam sobre os autores.

Programador Ultrawide Screen

Alguns programadores usam todo o espaço disponível de seus monitores para escrever seus códigos, pode ser muito fácil descobrir o tamanho do monitor de alguns desenvolvedores, basta contar quantas vezes você precisa rolar o código horizontalmente para descobrir se o desenvolvedor que o fez possui um monitor Ultrawide Screen.

Programador Shakespeariano

Esses programadores normalmente escrevem códigos que se encaixam no gênero de romance, suas obras são em geral muito belas, o único problema é que poucas pessoas são capazes de entendê-las.

Programadores que amam e odeiam espaço em branco

Alguns programadores amam usar a tecla de espaço, adicionam vários espaços entre seus códigos, seja verticalmente deixando um vasto espaço vazio entre funções, ou horizontalmente iniciando uma linha na metade da tela.

Por outro lado, há aqueles que a detestam, não incluem espaços entre elementos de uma linha, e muito menos entre blocos de funções, tudo se torna uma grande sequência de caracteres concatenados.

Conclusão

Ler e interpretar códigos compõem a maior parte do trabalho de um desenvolvedor, seja para integrar uma nova feature à um código já existente, corrigir um bug, ou refatorar algum trecho de código. Estamos sempre lendo códigos e tentando entender o que raios ele está fazendo, seja esse escrito por alguém da nossa equipe ou por nós mesmos há alguns meses. Por esse motivo, escrever de forma consistente e aplicar corretamente os padrões de desenvolvimento são tão importantes, isso nos ajuda a comunicar a intenção do código para as outras pessoas, e para nós mesmos no futuro.

O objetivo deste texto foi chamar a atenção de forma divertida para alguns anti-patterns e vícios negativos que temos no desenvolvimento de código, de forma que quando estejamos escrevendo algum código, nos perguntemos: que tipo de estória eu estou contando? Quem está lendo meu código se sentirá lendo um romance ou uma estória de terror?

É sempre mais agradável lidar com código claros e bem escritos, ainda que o código não seja o melhor, é possível notar quando o desenvolvedor se importava com o que estava fazendo, e queria entregar o melhor que podia naquele momento.

Dicas do autor

Quer deixar de escrever estórias de terror e começar a escrever verdadeiros romances? Que tal começar aplicando algumas estratégias de clean code básicas?

Preparei uma pequena lista de tópicos pensando no que vimos dentro dos gêneros literários deste artigo:

Nem todos os desenvolvedores possuem um super monitor, controle o comprimento das linhas do seu código, 80 caracteres é excelente, 120 é aceitável;
Se o arquivo está muito grande, separe o código em arquivos menores de acordo com as responsabilidades do código;
Separou o código em vários arquivos? Ótimo, agora os organize em pastas no seu projeto, não deixe tudo na pasta raiz;
Use nomes reveladores nas variáveis e funções, abreviaturas e usar apenas uma letra como variável dificulta muito a manutenção do código;
Certifique-se de que a função escrita faz o que o nome dela expressa;
Use o espaço vertical e horizontal, mas também não exagere, os elementos não precisam estar unidos, mas também não precisam estar em quarentena um longe do outro;
Siga apenas uma indentação, mesmo que não seja a melhor de todas ela demonstra consistência, poucas coisas mostram mais desleixo do que cada parte de um código escrito e indentado de formas completamente diferentes.

Lembre-se: escritores de livros não publicam a primeira versão de seus manuscritos, eles leem e releem suas obras e as lapidam, do mesmo jeito, você não deveria publicar a primeira versão do seu código, uma revisão ainda que rápida não fará mal a ninguém.

Agora, me conta: que tipo de gênero literário você tem escrito atualmente?

Referências

React e ficção: https://www.youtube.com/watch?v=kqh4lz2Lkzs
Livro: Código limpo: habilidades práticas do Agile software

CUIDADO: Seu Código Pode Estar Vulnerável. Descubra como Dependency Check + Azure DevOps + SonarQube = Segurança!

Luiz Felipe Lago — Fri, 15 Dec 2023 18:59:31 +0000

A segurança no desenvolvimento de software se torna cada vez mais crucial e a combinação de ferramentas eficientes é essencial para garantir a integridade e a proteção de aplicações.

Este artigo explora a integração do Dependency Check com o Azure DevOps, destacando a capacidade de unificar relatórios de segurança com o SonarQube por meio de um plugin oficial.

Dependency Check:

Visão Geral:
Desenvolvido e mantido pela OWASP (Open Web Application Security Project), o Dependency Check é uma ferramenta de código aberto que identifica e alerta sobre bibliotecas de terceiros com vulnerabilidades conhecidas. Suportando várias linguagens, o Dependency Check verifica dependências em busca de componentes suscetíveis a falhas de segurança, promovendo uma abordagem proativa à segurança. Documentação em OWASP DEPENDENCY CHECK

Integração com Azure DevOps:

A integração do Dependency Check com o Azure DevOps proporciona uma verificação contínua de vulnerabilides durante o ciclo de vida do desenvolvimento. Automatizando o processo de análise de segurança, essa integração garante a detecção e correção de vulnerabilidades antes que o código chegue à produção.
A task do Dependency Check para o Azure DevOps pode ser encontrada no Marketplace do Azure DevOps, acessível no link Azure DevOps Marketplace Essa tarefa permite a fácil incorporação do Dependency Check nos pipelines de build do Azure DevOps, simplificando a implementação da verificação de segurança.

Integração com SonarQube via Plugin:

Para centralizar os relatórios de segurança do Dependency Check no SonarQube, utiliza-se o plugin oficial disponível em Plugin Oficial. Este plugin permite uma integração fácil e eficiente, proporcionando uma visão consolidada dos resultados de segurança diretamente no Sonar.

Verificação de Compatibilidade com o SonarQube:

O plugin do Dependency Check para SonarQube é compatível com diversas versões do SonarQube. Antes de realizar a instalação, é recomendável verificar a documentação ou o repositório do plugin para garantir sua compatibilidade com a versão específica do SonarQube utilizada.

Benefícios da Integração:

Centralização de Relatórios: A integração com o SonarQube via plugin proporciona uma centralização eficiente de relatórios de segurança, simplificando a análise e o acompanhamento.
Análise Estática de Código: A combinação da verificação de dependências e vulnerabilidade do Dependency Check com a análise estática de código do SonarQube oferece uma visão holística da qualidade e segurança do código-fonte.
Detecção Antecipada de Problemas: A detecção precoce de vulnerabilidades, juntamente com métricas fornecidas pelo SonarQube, possibilita os desenvolvedores corrigirem problemas antes que impactem a segurança e a qualidade do software.

A integração do Dependency Check com o Azure DevOps, combinada com a centralização de relatórios no SonarQube por meio do plugin, oferece uma abordagem robusta para fortalecer a segurança no ciclo de vida do desenvolvimento. A colaboração entre essas ferramentas, permite a detecção e correção eficaz de vulnerabilidades, garantindo que as organizações possam oferecer software seguro, resiliente e de alta qualidade.

E vocês já conhecem o Fossology? Não? Essa assunto fica para o próximo capítulo dessas pílulas de segurança...

Gerenciando Processos Concorrentes: Estratégias e Dicas

Renan Osório — Fri, 24 Nov 2023 11:51:57 +0000

A programação concorrente é uma parte fundamental da computação moderna. À medida que os processadores evoluem e as aplicações se tornam cada vez mais complexas, a capacidade de executar múltiplas threads ou processos simultaneamente se torna essencial para otimizar o desempenho e a responsividade dos sistemas. No entanto, essa abordagem traz consigo o desafio de lidar com a concorrência, na qual várias threads competem por recursos compartilhados. E é aí que entram os conceitos de Mutex e Lock, duas ferramentas cruciais para gerenciar essa concorrência de maneira eficaz.

Esses recursos desempenham um papel fundamental em cenários nos quais é imperativo assegurar que apenas uma thread execute o recurso, prevenindo assim duplicação. Esse mecanismo de bloqueio é aplicado por um intervalo de tempo definido, o que significa que um método é temporariamente retido por uma thread durante um período determinado com o propósito de garantir que nenhuma outra thread execute o mesmo método simultaneamente.

Esses conceitos fazem o bloqueio de threads concorrentes tanto em aplicações que possuem uma única instância, quanto em aplicações distribuídas em diversas instâncias como, por exemplo, o uso de clusters.

Neste artigo, pretendo elucidar alguns conceitos e oferecer orientações para a implementação de Mutex e Lock.

Tempo de Expiração e Base de dados

A base de dados é responsável por guardar os dados dos processos que estão bloqueados. Por exemplo, quando for pagar um boleto, deve ser gravado no banco uma chave com os dados desse boleto para indicar que esse boleto está sendo processado. E, ao fazer isso, é preciso indicar por quanto tempo esse recurso será bloqueado.

O recomendado é utilizar uma base de dados que já possua um recurso automático de expiração de dados, já que os dados nela são voláteis. Além disso, essa base de dados deve ser rápida para leitura e gravação.

Recomendo a utilização do Redis, e, nele, gravar um json com os seguintes dados:

"registro": {
        "key": "lib_lock:appName:Environment:IdBoleto",
        "threadId": 0,
        "hostName": "",
        "processName": "",
        "processId": 0,
        "nameOf": "",
        "dataCriacao": "",
        "tempoExpiracao": "",
        "tempoRestanteExpiracao": ""
  }

O redis é um banco de chave e valor. A chave será a mesma que está no json citado anteriormente, e o valor será todo o json citado.

Chave

O controle de bloqueio é feito através de uma chave, que contém dados necessários para distinguir processos, ambientes e o registro que está sendo bloqueado.

Assim, garantimos que, quando gravarmos uma chave na base de dados, esse registro não será processado novamente sem que a chave expire ou seja deletada da base de dados.

O ideal é uma padronização de uma chave, podemos fazer da seguinte maneira:

Chave Lock

lib_lock:NomeAplicacao:Environment:Boleto-11111

Chave Mutex

lib_mutex_queue:NomeAplicacao:Environment:Boleto-11111:HostaName:ThreadId:ProcessId

Como o Mutex faz controle de fila das threads, é necessário ter mais dados na chave para facilitar o trabalho de distinguir os itens na fila.

O atributo Boleto-1111 que está na chave informa o tipo do dado, que nesse caso é um boleto, e mostra o identificador único do registro, que nesse caso é 1111. Já os demais dados podem ser preenchidos da forma que achar mais adequada para o seu projeto.

Mutex

O termo "Mutex" é a abreviação de "Mutual Exclusion", o que significa exclusão mútua. Essencialmente, um Mutex é um mecanismo de sincronização usado para garantir que apenas uma thread por vez tenha acesso a um recurso compartilhado. Uma das funcionalidades mais valiosas do Mutex é a sua capacidade de enfileirar threads concorrentes.

Fluxo

O funcionamento geral do Mutex é ilustrado na imagem abaixo.

WaitOne

É necessário que o Mutex tenha o recurso de WaitOne, que é responsável por gravar na base de dados que um determinado recurso está bloqueado e ficar travado até que chegue a sua vez de processar o recurso.

O WaitOne é responsável também por realizar a sincronia da fila no redis.

Processo Lógico de Mutex

Na imagem abaixo, temos o processo sugerido para fazer um controle de Mutex por meio do WaitOne e garantir que tenha um enfileiramento de threads:

Lock

O "Lock" representa outra abordagem para controlar threads concorrentes. Nesse cenário, o "Lock" bloqueia um processo por um período definido, e todas as futuras threads que tentarem acessar o mesmo recurso já bloqueado serão encerradas.

A principal diferença entre o "Mutex" e o "Lock" reside no fato de que o "Mutex" enfileira todas as threads que tentam acessar um recurso já bloqueado e, à medida que essas threads são processadas, permite que a próxima thread seja executada. Por outro lado, o "Lock" encerra todas as threads concorrentes, permitindo que apenas uma única thread seja executada.

Fluxo

O funcionamento geral do Lock é ilustrado na imagem abaixo.

AcquireLock

Essa funcionalidade tem a responsabilidade de registrar o processo que está sendo bloqueado na base de dados. Caso o processo já esteja bloqueado, deve gerar uma exceção.

Ao contrário do "WaitOne", essa funcionalidade não cria nem gerencia filas, ela apenas encerra a requisição.

ReleaseLock

O Mutex e o Lock devem ambos possuir a funcionalidade de "ReleaseLock", que tem a responsabilidade de desbloquear o processo na base de dados.

O desbloqueio do processo na base de dados pode ser alcançado de duas maneiras: por meio da expiração do dado na base de dados (caso esteja sendo utilizado o Redis) ou simplesmente removendo-o da base de dados usando a função "ReleaseLock".

Por exemplo, ao concluir o processamento de um boleto, o "ReleaseLock" será invocado, resultando na remoção da chave correspondente a esse boleto na base de dados.

KeepLock e/ou DelayMutex

Este recurso pode ser bastante útil, pois permitirá estender o período de bloqueio, caso seja necessário. Por exemplo, se houver algum trecho de código que, no pior cenário, possa resultar em longos atrasos, pode ser necessário ajustar a duração do bloqueio do registro no banco de dados. Esse recurso pode ser denominado como "KeepLock" quando se refere ao bloqueio de Lock, e "DelayMutex" quando se relaciona ao Mutex.

Monitoramento

É fundamental contar com um sistema de monitoramento para os logs gerados por todos os recursos de Mutex e lock, bem como monitorar a base de dados onde os dados de bloqueio são registrados. Isso permite garantir a estabilidade da base de dados, identificar possíveis quedas e evitar bloqueios prolongados de dados.

Recomendamos que você e sua equipe de arquitetos avaliem qual é a ferramenta de monitoramento mais adequada para o seu cenário.

Conclusão

Os recursos mencionados são de suma importância para sistemas que necessitam assegurar que determinados recursos não sejam processados múltiplas vezes ou simultaneamente.

Vale ressaltar que há diversas maneiras de implementar um Mutex ou Lock em seu projeto. Contudo, desde que sigam padrões estabelecidos e garantam a confiabilidade das execuções concorrentes de threads, evitando a duplicação de processamento de recursos, sua aplicação se tornará mais confiável, reduzindo custos desnecessários.

Angular v10 vs v15: Principais mudanças e melhorias

vandrei de lima — Mon, 23 Oct 2023 16:38:05 +0000

Olá!

Neste artigo, vou apresentar as principais melhorias e atualizações que ocorreram entre o Angular 10 e a versão 15 do framework. A migração de projetos Angular é crucial para aprimorar o desenvolvimento e a experiência final dos usuários. Para aqueles que atualmente utilizam em seus projetos o Angular 10, especialmente em conjunto com o Angular Material, é fundamental planejar a migração a fim de aproveitar ao máximo os recursos aprimorados disponíveis no Angular 15. O propósito deste artigo é fornecer uma lista das atualizações mais significativas e orientações sobre as migrações.

Dentro das atualizações, tivemos melhorias significativas no core e no processamento do build e melhorias e avanços no NGCC (Angular compatibility compiler) que podem trazer uma velocidade de compilação de até 4x mais rápido, trazendo mais velocidade para o desenvolvimento.

A versão 10 do angular consegue utilizar até a versão 3.9 do typescript e na 15 temos um grande avanço, podendo utilizar até a versão 5.0, trazendo benefícios e novas ferramentas para o desenvolvimento. Além disso, tivemos melhorias visuais na estrutura de log, facilitando a busca de problemas que podem ocorrer no desenvolvimento. Nas versões mais recentes, tivemos a depreciação do TSLint, de forma que agora é necessário migrar para o ESlint.

Foi adicionado também o “Hot Module Reloading”, que uma vez ativado não requer a atualização de toda a tela quando é feita uma mudança em algum módulo ou componente. Isso também traz velocidade para quando estivermos fazendo alterações em alguma tela na qual o tempo de carregamento é alto.

Para ativar o HMR, basta iniciar o server utilizando o parâmetro --hmr:

ng serve --hmr.

Agora, também podemos utilizar a coalescência nula no template e, com isso, além de poder utilizar a condição ternária, também podemos criar condições de forma mais simples. Confira o exemplo abaixo:

Ternario
{{age !== null && age !== undefined ? age : entity.age }}

Coalescência nula
{{ age ?? entity.age }}

A estrutura de um projeto angular é separada por módulos. E isso para quem está iniciando pode gerar um pouco de confusão. Mas não se preocupe, não é nada complexo: o lado positivo dos módulos é conseguir gerar um carregamento por demanda e com isso só será executado o código que for necessário. Isso ajuda a evitar carregamento desnecessário de script.

O problema atual é o seguinte: ao criar um dumb component (componente genérico sem regra de negócio) que seria compartilhado com outros módulos, você precisa criar um módulo apenas para ele e com isso importar nos módulos os locais nos quais gostaria de utilizar. Porém, na versão 14 do angular, foi estabilizado os “standalones” componentes, no qual um componente pode importar outros módulos para utilizar e pode ser importado por qualquer outro módulo, sendo independente de um módulo pai.

Isso ajuda e facilita bastante, sem essa ferramenta alguns projetos criam os “sharedModule” nos quais eles importam e declaram vários componentes. E o problema é que às vezes queremos utilizar apenas um ou dois componentes e precisamos importar o módulo inteiro. Com os “standalones” componentes, isso será resolvido: você apenas importará os componentes necessários, diminuindo a quantidade de código carregado pelo navegador.

Aqui está um exemplo de como seria um "standalone component":

@Component({
  standalone: true,// declara um standalone component
  selector: 'photo-gallery',
  imports: [ImageGridComponent], // importa os modulos utilizados por ele
  template: `
    ... <image-grid [images]="imageList"></image-grid>
  `,
})
export class PhotoGalleryComponent {
  // component logic
}

Agora, basta importar esse componente no módulo que deseja utilizar e pronto: estará pronto para o uso.

Para a injeção de dependência, tivemos algumas melhorias e a maneira de declarar ficou facilitada. A partir de agora, temos o método inject() e a sua principal vantagem é poder realizar a injeção de dependência sem precisar declarar explicitamente o tipo do parâmetro, de forma a tornar o código mais limpo e legível.

Veja o exemplo abaixo:

import { inject } from '@angular/core';
import { ActivatedRoute } from '@angular/router';

export function getRouteParam(key: string) {
  return inject(ActivatedRoute).snapshot.params[key];
}

@Component({
  selector: 'app-todo-page',
  templateUrl: './todo-page.component.html',
})
export class TodoPageComponent {
  id = getRouteParam('id');

  ngOnInit() {
    console.log(this.id)
  }
}

Tivemos melhorias gerais de acessibilidade, tanto para os componentes como para as rotas, que deixaram os componentes mais estáveis. Além disso, tivemos melhorias nas diretivas, de forma a permitir a inclusão nos elementos host e a estabilizar as diretivas para imagens.

Agora, se você for realizar uma migração extensa como essa partindo do angular 10 para o 15, eu tenho aqui algumas recomendações:

Comece a migração como uma escada, não parta do 10 direto para o 15, vá subindo gradualmente as versões do angular. Isso evita dores de cabeça e facilita identificar caso alguma biblioteca fique estagnada e não possa mais ser utilizada. Verifique a lib dos componentes e, caso esteja utilizando o angular material, fique atento às alterações de certos componentes (alguns mudaram até os seletores).

Conclusão

Neste artigo, exploramos as principais mudanças que ocorreram no Angular, desde a versão 10 até a versão 15. Ao destacar essas transformações, meu objetivo foi proporcionar a você uma compreensão mais clara das novas ferramentas e recursos disponíveis, e mostrar como você pode aproveitá-los para melhorar o desenvolvimento de seus aplicativos Angular.

No entanto, é fundamental notar que o Angular é uma plataforma em constante evolução. A partir da versão 16, testemunhamos mudanças significativas, inclusive na abordagem para o gerenciamento de estado e em muitos outros aspectos.

Portanto, se você estiver considerando a migração para as versões mais recentes do Angular, este artigo serviu como um ponto de partida, mas é altamente recomendável manter-se atualizado com a documentação oficial e as comunidades do Angular para aproveitar ao máximo essas novas oportunidades.

Executando funções personalizadas no banco de dados usando SqlExpression no .Net

Mauricio Redmerski André — Sat, 06 May 2023 20:26:24 +0000

Olá, pessoal! Espero encontrar todos bem. Hoje teremos um material "mão na massa", demonstrando como fazer o EF Core (Entity Framework Core) ser capaz de traduzir funções personalizadas no banco de dados em expressões construídas com Linq (Consulta Integrada à Linguagem), que normalmente, não seria possível traduzi-las.

Se você trabalha com a linguagem de programação C#, certamente já escreveu alguma query com Linq que executa perfeitamente quando a lista de dados da operação envolvida já está carregada em memória, mas teve uma triste surpresa ao tentar aplicar o mesmo código acessando dados que estavam no banco, recebendo algum erro similar a este:

 The LINQ expression could not be translated

Isso ocorre porque há um limite acerca do que o EF Core é capaz de traduzir para linguagem nativa do banco de dados configurado em seu projeto, restringindo assim as possibilidades de uso do que pode ser feito diretamente no banco, em ralação ao que pode ser feito quando os dados já estão em memória. Mas há uma luz no fim do túnel, e não se preocupe, não é um trem vindo em sua direção... Podemos usar o recurso SqlExpression para ensinar o EF Core a traduzir comandos que ele nativamente não consegue, sendo essas operações nativas do seu banco de dados, ou funções criadas por você dentro do banco de dados.

Antes de começarmos efetivamente, vamos dar uma olhada nas versões de pacotes e programas que estou usando, sabemos que o modo como os recursos são implementados podem variar de acordo com suas versões, então para não haver mal-entendidos, estou usando o .Net 5 e o banco de dados SQL Server 2016, um pouco datado, eu sei.

Vamos começar com um problema simples. Imagine que você precise realizar uma consulta em uma massa de dados de Players, e retornar às seguintes propriedades: Name, Score, e a posição do player no ranking, que claro, é calculado a partir do Score. Para atender a essa demanda, um simples código como o seguinte pode ser usado

var playerList = new List<Player>()
{
    new Player() { Name = "Mauricio", Score = 10 },
    new Player() { Name = "André", Score = 6 },
    new Player() { Name = "Redmerski", Score = 8 },
};

var playerDtoList = playerList
    .OrderByDescending(player => player.Score)
    .Select((player, index) => new PlayerDto()
    {
        Name = player.Name,
        Score = player.Score,
        Position = index + 1,
    })
    .ToList();

Esse código funciona perfeitamente porque os dados que esse algoritmo manipula estão carregados em memória, se você trocar a variável playerList de modo a apontar para uma base de dados, usando dbContext.PlayersDbSet por exemplo, descobrirá que isso não pode ser traduzido para um comando SQL. O parâmetro index contido no Select representa a posição do item percorrido dentro da lista carregada em memória, logo se os dados não estão em memória, essa informação não existe. Poderíamos esperar que essa posição fosse substituída pela função do banco de dados que determina a linha da consulta, chamado de ROW_NUMBE no SQL Server, mas o EF Core não tem uma forma simples de executar essa operação para retornar o número da linha do registro em uma consulta ao banco de dados.

PS: Eu sei que você está com vontade de comentar que esse código não prevê a possibilidade de dois ou mais jogadores estarem empatados, mas quero manter as coisas simples, então segura essa vontade 😁.

Certo, então como podemos tornar essa operação traduzível ao banco de dados? Muito simples meu caro leitor, basta seguirmos os passos abaixo. Ah, os nomes e estruturas que mostro abaixo são uma representação de como eu acredito que essas funções devem ser organizadas, fique à vontade para alterá-las.

Começamos criando um diretório dentro do seu projeto responsável por lidar com a infraestrutura, especificamente o banco de dados, chamo essa pasta de Functions, dentro dessa pasta crio um arquivo chamado EfCoreCustomFunctions, dentro desse crio uma função chamada RowNumber que recebe três parâmetros, um parâmetro do tipo long que representará a coluna do banco de dados também do mesmo tipo que será usada para particionar a enumeração, um segundo parâmetro do tipo long que representará a coluna pela qual a ordenação deve ser aplicada para a enumeração, e um parâmetro booleano que indica a direção de ordenação, quando verdadeiro a ordem é ascendente. Observe que o conteúdo dessa função não é importante, então podemos simplesmente lançar uma exceção.

using System;

namespace MyProject.EntityFrameworkCore
{
    public static class EfCoreCustomFunctions
    {
        public static double RowNumber(long? partition, long ordering, bool ascending)
            => throw new NotSupportedException();
    }
}

Em seguida crio um arquivo na mesma pasta chamado RowNumberFunction, é dentro desse arquivo que a função realmente será criada. Nesse arquivo crio uma função de extensão para a classe ModelBuilder.

namespace MyProject.EntityFrameworkCore
{
    public static class RowNumberFunction
    {
        public static ModelBuilder AddRowNumberFunction(this ModelBuilder modelBuilder)
        {
            return modelBuilder;
        }
    }
}

A primeira coisa a ser feita é recuperar o tipo da classe que criamos para manter as assinaturas dos nossos métodos, e usar a função GetMethod para capturar a assinatura do método específico desejado. Eu gosto de especificar explicitamente os tipos dos parâmetros da função em questão, passando-os como segundo parâmetro da função GetMethod, mas se houver apenas uma função com o nome especificado, essa etapa é opcional.

var method = typeof(EfCoreCustomFunctions)
    .GetMethod(
        nameof(EfCoreCustomFunctions.RowNumber),
        new[] { typeof(long?), typeof(long), typeof(bool) });

Em seguida vem o passo mais importante: instruir o EF Core de fato a como traduzir esse comando, e podemos fazer isso de algumas formas

Depois de usar o modelMuilder para chamar a função HasDbFunction passando como parâmetro a variável method criada na etapa anterior, podemos usar a função HasName e passar o nome de uma função personalizada que nós criamos diretamente no banco.

modelBuilder.HasDbFunction(method).HasName("MinhaFuncaoJaCriadaNaBase");

Eu particularmente não gosto de criar funções diretamente no banco de dados, entendo como a melhor opção usarmos o método HasTranslation após a função HasDbFunction, esse método nos permite instruir o EF Core a como a operação precisa ser criada, sem que a função exista previamente na base, assim mantemos todas as regras de operação dentro do nosso programa. É claro que esse é um posicionamento particular, a função HasName existe para ser usada, então fique à vontade para fazer uso da mesma caso ela atenda ao seu cenário.

A função HasTranslation recebe uma function que contém uma lista de SqlExpression, essa lista é uma representação dos parâmetros que foram enviados para a função, e retorna um SqlExpression que será a função a ser executada. Sim, os tipos de entrada e saídas são iguais, isso porque o parâmetro da sua função pode ser o resultado de uma outra função traduzida para o banco.

A operação RowNumber em que estamos trabalhando possui a classe RowNumberExpression que facilita sua implementação e é herdeira de SqlExpression. Essa classe recebe como parâmetro uma lista opcional com os campos da base a serem usados como partição de agrupamento para a enumeração das linhas, uma lista obrigatória da classe OrderingExpression que contém o nome da coluna a ser usada na ordenação e a direção de ordenação, e o tipo de retorno esperado.

modelBuilder.HasDbFunction(method)
    .HasTranslation(args =>
        new RowNumberExpression(
            null,
            new List<OrderingExpression>()
            {
            },
            new LongTypeMapping("long", DbType.Int64)));

Os parâmetros da função RowNumber que criamos em nossa classe EfCoreCustomFunctions são um pouco diferentes do que é esperado, então vamos manipulá-los um pouco. Primeiro vamos verificar se o primeiro parâmetro que enviamos é do tipo SqlConstantExpression, qualquer constante enviada geraria o mesmo resultado, então eu prefiro testar essa condição, e caso ela seja verdadeira, passar o valor null como parâmetro.

modelBuilder.HasDbFunction(method)
    .HasTranslation(args =>
        new RowNumberExpression(
            args.First() is SqlConstantExpression
                ? null
                : args.Take(1).ToList(),
            new List<OrderingExpression>()
            {
            },
            new LongTypeMapping("long", DbType.Int64)));

Em seguida vamos criar um item na lista passada como segundo parâmetro, esse item vai ter os outros dois campos que recebemos em nossa função de ordenação personalizada. Observe que dada a natureza do tipo do objeto args, precisamos primeiro converter o terceiro parâmetro recebido para SqlConstantExpression para só então conseguir convertê-lo para booleano.

modelBuilder.HasDbFunction(method)
    .HasTranslation(args =>
        new RowNumberExpression(
            args.First() is SqlConstantExpression
                ? null
                : args.Take(1).ToList(),
            new List<OrderingExpression>()
            {
                new OrderingExpression(
                    args.Skip(1).First(),
                    ((bool)((SqlConstantExpression)args.Skip(2).First()).Value))
            },
            new LongTypeMapping("long", DbType.Int64)));

O código final dessa classe deve se parecer com o seguinte:

using System.Collections.Generic;
using System.Data;
using System.Linq;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Query.SqlExpressions;
using Microsoft.EntityFrameworkCore.Storage;

namespace MyProject.EntityFrameworkCore
{
    public static class RowNumberFunction
    {
        public static ModelBuilder AddRowNumberFunction(this ModelBuilder modelBuilder)
        {
            var method = typeof(EfCoreCustomFunctions)
                .GetMethod(
                    nameof(EfCoreCustomFunctions.RowNumber),
                    new[] { typeof(long?), typeof(long), typeof(bool) });

            modelBuilder.HasDbFunction(method)
                .HasTranslation(args =>
                    new RowNumberExpression(
                        args.First() is SqlConstantExpression
                            ? null
                            : args.Take(1).ToList(),
                        new List<OrderingExpression>()
                        {
                            new OrderingExpression(
                                args.Skip(1).First(),
                                ((bool)((SqlConstantExpression)args.Skip(2).First()).Value))
                        },
                        new LongTypeMapping("long", DbType.Int64))
                    );

            return modelBuilder;
        }
    }
}

Agora tudo que temos que fazer é chamar a construção desse método dentro do ModelBuilder, para que quando tentarmos usá-lo, ele saiba exatamente o que fazer. Para isso, vamos criar uma classe chamada ModelFunctionsExtensions dentro da pasta Functions, vamos usar esse arquivo para chamar todas as funções customizadas que criaremos no futuro.

using Microsoft.EntityFrameworkCore;

namespace MyProject.EntityFrameworkCore
{
    public static class ModelFunctionsExtensions
    {
        public static ModelBuilder AddCustomFunctions(this ModelBuilder modelBuilder)
        {
            modelBuilder.AddRowNumberFunction();

            return modelBuilder;
        }
    }
}

Agora no local onde você cria o seu contexto, tudo que você tem a fazer é incluir a seguinte linha builder.AddCustomFunctions(); e todas as configurações estarão prontas. É claro que a variável builder é uma instância de ModelBuilder.

Agora vamos ver como podemos alterar o nosso código de exemplo para usar a função que acabamos de criar. Primeiro vamos acessar os dados diretamente do contexto, e na atribuição da propriedade Position, vamos chamar nossa função RowNumber.

var playerDtoList = playerList
    .OrderByDescending(player => player.Score)
    .Select(player => new PlayerDto()
    {
        Name = player.Name,
        Score = player.Score,
        Position = EfCoreCustomFunctions.RowNumber(null, player.Score, false)
    })
    .ToList();

Pronto! Esse código será capaz de ser traduzido pelo EF Core, e a posição do player será calculada diretamente no banco de dados. Veja um exemplo de como essa query se parecerá quando for executada no banco de dados.

SELECT Name, Score, ROW_NUMBER() OVER(ORDER BY Score DESC) as Position
FROM Playes
ORDER BY Score DESC

Que tal olharmos rapidamente mais um exemplo de função, mas dessa vez um exemplo que use a classe SqlFunctionExpression? Essa classe recebe como primeiro parâmetro o nome da função a ser executado, os argumentos a serem transmitidos, um indicador se o retorno pode ser nulo, e uma lista com o mesmo número de argumentos passados que representa a possibilidade de os parâmetros enviados serem nulos, um parâmetro do tipo System.Type e outro RelationalTypeMapping respectivamente, ambos indicando o tipo de retorno da função.

Vamos criar um método que chama a função Replicate do banco de dados, começamos incluindo a função Replicate à nossa classe EfCoreCustomFunctions.

using System;

namespace MyProject.EntityFrameworkCore
{
    public static class EfCoreCustomFunctions
    {
        public static double RowNumber(long? partition, long ordering, bool ascending)
            => throw new NotSupportedException();

        public static string Replicate(string replicate, int length)
            => throw new NotSupportedException();
    }
}

Agora criamos o nosso arquivo ReplicateFunction e criamos um conteúdo muito semelhante ao exemplo anterior, mas agora usando SqlFunctionExpression.

using System.Collections.Generic;
using System.Data;
using System.Linq;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Query.SqlExpressions;
using Microsoft.EntityFrameworkCore.Storage;

namespace MyProject.EntityFrameworkCore
{
    public static class ReplicateFunction
    {
        public static ModelBuilder AddReplicateFunction(this ModelBuilder modelBuilder)
        {
            var method = typeof(EfCoreCustomFunctions)
                .GetMethod(
                    nameof(EfCoreCustomFunctions.Replicate),
                    new[] { typeof(string), typeof(int) });

            modelBuilder.HasDbFunction(method)
                .HasTranslation(args =>
                    new SqlFunctionExpression(
                        "REPLICATE",
                        args,
                        false,
                        args.Select(x => false),
                        typeof(string),
                        new StringTypeMapping("string", DbType.String))
                    );

            return modelBuilder;
        }
    }
}

Agora basta incluir a linha modelBuilder.AddReplicateFunction(); na função AddCustomFunctions do arquivo ModelFunctionsExtensions e nossa função já está pronta para ser usada.

Nota do autor

Conhecer recursos como esses a respeito da ferramenta com a qual trabalhamos é muito importante, e nos permite fazer coisas incríveis em nossas aplicações. Espero que esse artigo o tenha ajudado a resolver o que você precisava, ou ao menos incluído mais uma ferramenta em sua caixa de ferramentas para lidar com o complexo e maravilhoso mundo da programação.

Abraço!

Fontes e leituras complementares

https://learn.microsoft.com/en-us/ef/core/querying/user-defined-function-mapping

https://www.allhandsontech.com/data-professional/entityframework/entity-framework-core-advanced-mapping/

https://khalidabuhakmeh.com/add-custom-database-functions-for-entity-framework-core

https://stackoverflow.com/questions/56261258/mixing-ef-core-convensions-and-dbfunction-for-a-jobject-property

https://medium.com/@pawel.gerr/entity-framework-core-custom-functions-using-hasdbfunction-191dd57e4967

https://medium.com/@pawel.gerr/entity-framework-core-custom-functions-using-imethodcalltranslator-f8209ae6f95b

Uso do Codeball em projetos C#

Ricardo Fontana — Wed, 19 Apr 2023 14:44:24 +0000

São inegáveis os benefícios da revisão de código, como a redução do número de bugs, melhora da legibilidade do código, fortalecimento da cultura de feedback, entre outros. Porém, seguindo o velho princípio da física onde toda ação promove uma reação inversa e diretamente proporcional, a revisão de código pode gerar alguns "desconfortos" como a falta de clareza tanto por parte do autor quanto do revisor, falta de padronização e demora na revisão. A ferramenta codeball.ia promete atuar neste último cenário, fazendo a revisão e aprovação automática dos pull requests. Para isso, a ferramenta utiliza algoritmos de inteligência artificial com percepção multinível e, segundo o site da ferramenta, são considerados critérios que vão desde o número de linhas alteradas até a classificação do tipo de arquivo. Baseando-se nestes critérios, a ferramenta gera um indicador do "percentual de confiança na alteração" e pode-se então definir algumas ações para este percentual como: aprovação automática ou adicionar uma marcação com o resultado.

O blog da ferramenta ainda lista um caso de testes onde o codeball é comparado com PR previamente revisados. Este exemplo enfatiza que não houve falsos positivos durante o teste, sendo que este realmente parece ser o cenário mais catastrófico na utilização da ferramenta.

Caso seu código esteja disponível no github, a instalação é extremamente simples: basta adicionar a action do codeball no workflow (no momento está sendo disponibilizada apenas a integração com o Github). A ferramenta é gratuita para projetos open source, para os demais há o custo de US$ 10,00 por usuário/mês, conforme o próprio site, entende-se por usuário o autor do pull request. No site existe ainda uma frase que chama muito a atenção "Pay only if Codeball saves you money" sem dar maiores detalhes sobre como obter este tipo de isenção.

Para avaliar a eficiência do Codeball em projetos que utilizam dotnet e c#, selecionamos projetos que foram tendência no github em fevereiro de 2023, os procedimentos de pull request foram reproduzidos novamente a fim de se verificar se a ferramenta terá o mesmo resultado.

PR	Confidence
https://github.com/PowerShell/PowerShell/pull/19119	0.284
https://github.com/PowerShell/PowerShell/pull/19092	0.372
https://github.com/PowerShell/PowerShell/pull/19111	0.360
https://github.com/actions/runner/pull/2423	0.376
https://github.com/actions/runner/pull/2396	0.136

Posteriormente, foi feito o mesmo procedimento de avaliar a eficiência dos projetos, porém utilizando repositórios internos da Becomex. O objetivo desta segunda bateria é verificar como a ferramenta se comporta com diferentes perfis de desenvolvedores ou mesmo se ela considera detalhes da localização do software na sua execução.

Apesar do indicador de confiança apresentar melhora significativa, passando para aproximadamente 0.5, não foi o suficiente para a aprovação do PR. Não foi possível alcançar o

percentual mínimo para aprovação mesmo em pequenas alterações que não comprometem o funcionamento da aplicação. Um exemplo deste tipo de alteração é a utilização dos recursos mais recentes da linguagem para a mesma funcionalidade.

Dados os resultados alcançados, acredito que este é o momento ideal para nos fazermos uma indagação:

Eu preciso de uma IA para auxiliar a revisar meus pull requests?

Mas antes de responder esta pergunta devemos saber qual é o objetivo da organização ao estabelecer o procedimento de pull request, somente com um objetivo claro e quantificável, com por exemplo "Identificar e corrigir 30% dos bugs" ou "Garantir que pelo menos três desenvolvedores possam dar manutenções numa rotina" podemos definir a eficácia do processo. Definido o objetivo, podemos então estabelecer indicadores para medir a efetividade do processo, por exemplo, caso o objetivo seja a identificação dos bugs pode-se rastrear issues de bugs ao PR que as gerou, se o seu objetivo é garantir que mais desenvolvedores entendam uma rotina, pode-se verificar o tempo médio que um desenvolvedor utiliza para fazer manutenção em parte do código.

A definição e rastreamento dos objetivos torna a adoção de uma IA como revisora de pull requests menos traumáticas, mas imaginando que a ferramenta irá alcançar o seu objetivo de aprovação de 63%, que conforme o site da ferramenta corresponde aos PR aprovados sem qualquer comentário, ou mesmo LGTM (Looks Good To Me), sua adoção é necessária?

Deste ponto do artigo em diante trago apenas a minha opinião.

Nem toda alteração precisa ser revisada. Acredito que a revisão de código é um dos mecanismos de revisão de produto que podem ser adotados por uma empresa, outras revisões de produto são o teste pela equipe de qualidade e a homologação pela equipe de suporte ou mesmo pelo cliente. Dependendo de algumas variáveis como o nível da alteração, a criticidade da rotina alterada e o nível do desenvolvedor, nem toda rotina precise passar por uma revisão de código. Obviamente este tipo de decisão não deve ficar ao sabor do momento, o ideal é que durante o planejamento a equipe decida quais alterações precisam de uma revisão mais detalhada e quais não.

Sei que este pode ser o tipo de opinião impopular, mas deixar a decisão nas mãos da equipe é a melhor maneira de envolvê-los no processo, também é da equipe a responsabilidade sobre o número de bugs e sua correção.

Conversando com alienígenas, uma breve introdução ao Gherkin

Mauricio Redmerski André — Thu, 16 Feb 2023 19:55:34 +0000

Olá, pessoal! Espero encontrar todos bem. Hoje vocês aprenderão a se comunicar com uma espécie muito curiosa e intrigante que vive sobre a superfície do nosso pálido ponto azul - ou planeta Terra se você não for tão íntimo.

Mas, antes de começarmos, preciso esclarecer uma coisa: se você começou a ler esse artigo esperando aprender a conversar com alienígenas de verdade, e talvez pensou que Gherkin fosse alguma máquina maluca de tradução de linguagens intergalácticas, detesto te desapontar, mas esse artigo não é bem sobre isso. Mas não desista de ler ele agora, prometo que esse material pode ser útil para você (mesmo se você realmente estiver querendo falar com aliens).

Certo, então qual é a espécie intrigante a qual eu me referi no começo do artigo? E sobre o que é esse material afinal?

No contexto deste artigo, quando falo em alienígenas, faço uma brincadeira com as pessoas da categoria a qual pertenço, me refiro a programadores e programadoras (devs) que em geral tem uma forma muito peculiar de interpretar o que as pessoas falam - darei exemplos e deixarei a analogia mais clara adiante. Esse artigo faz uma introdução a uma sintaxe, um modo de escrever determinado contexto, que elimina termos que possam não ser conhecidos por todos os interlocutores fazendo-o de uma forma declarativa, deste modo todos são capazes de compreender o contexto e qual é a mensagem a ser transmitida, aumentando assim a eficiência da comunicação entre os membros de um time em um ambiente de desenvolvimento de software, e claro, tornando mais fácil para nós desenvolvedores entender o que precisa ser feito. E o nome dessa estrutura mágica é Gherkin.

Problemática

Vamos fazer o seguinte experimento mental: imagine que uma nave alienígena pouse na sua frente, dela sai um homenzinho verde com clara capacidade de manter uma comunicação complexa, mas você não entende um único som que esse visitante espacial emite, e ele também não possui nenhum conhecimento prévio sobre sua língua e cultura. O que você faria para tentar compreender o que nosso visitante está dizendo e como você ensinaria a ele nossa língua para que ele pudesse nos entender?

A ideia de trazer esse experimento é causar a reflexão sobre como podemos nos comunicar com pessoas que não possuem o mesmo background que nós, que possuem outras ideias, onde aquilo que é óbvio para nós não é óbvio para nossos ouvintes. Nessa analogia, o homenzinho verde são os devs, e a questão é como um analista de negócio, gerente de produto ou qualquer outro estabelece contato conosco e nos solicita o desenvolvimento de uma nova funcionalidade. É claro que os papéis de marciano e terrestre podem ser facilmente invertidos, e que essa reflexão não vale apenas para comunicações onde devs estão envolvidos, mas também com qualquer pessoa, lembre-se que não é porque você fala a mesma linguagem que alguém, que não existirão ruídos na comunicação.

Mais uma historinha

Talvez você já tenha ouvido a piada onde alguém pede para um dev ir ao mercado com a seguinte instrução "Compre uma caixa de leite, e se tiver ovos traga dois" e assim o dev compra duas caixas de leite ao invés de uma caixa de leite e dois ovos como o solicitante queria. A piada pode ser engraçada, mas não é nada divertido quando essas confusões acontecem durante o desenvolvimento de um software, e a feature implementada não faz o que o solicitante esperava.

Por essa razão, o modo como uma funcionalidade deve ser descrita é muito importante, não só para o programador, mas para que todos os envolvidos no processo de construção de um software tenham o mesmo entendimento do que deve ser feito.

Só para constar, acho totalmente aceitável comprar duas caixas de leite considerando a instrução fornecida.

Falando sobre Gherkin

Gherkin é um dos elementos presentes no BDD (Behavior Driven Development) e basicamente consiste em escrever cenários de forma padronizadas, baseadas nas regras de negócio e usando palavras-chave para compor os passos que devem ser seguidos até uma conclusão, sendo sempre escritas na terceira pessoa.
Apesar de descrever as regras de negócio, o uso de palavras e termos que pertencem ao negócio deve ser evitado, é ideal que qualquer pessoa consiga ler e interpretar o que deve ser feito, mesmo que não possuam conhecimento de negócio. Em igual medida, termos técnicos e exemplo de codificação devem ser omitidos, essa especificação é o ponto onde todos os envolvidos na construção do software se encontram, sendo assim não pode haver termos que só um dos lados entenda.

Além do motivo supracitado para não acrescentar códigos na solicitação de uma demanda, existe outra boa razão para não fazer isso, o maior valor que um desenvolvedor entrega não é quanto código ele escreve, mas os problemas que ele resolve, somos bons em resolver problemas e gostamos disso, entregar o problema resolvido para "apenas" escrever o código elimina a maior entrega de valor que podemos dar, além de nos matar vagarosamente.

Os arquivos com a estrutura Gherkin são normalmente salvos com a extensão feature e possuem notações iniciadas com cerquilha # para indicar por exemplo a linguagem das palavras-chave usadas naquele arquivo, a indentação do conteúdo é estruturado com espaços e quebra de linha, deste modo o aninhamento do conteúdo e as palavras-chave são identificadas. Essas especificações são especialmente importantes se você for manter esses conteúdos escritos em arquivos, mas nada o impede de usar a caixa de texto de algum sistema para manter esse conteúdo, a fim de usar a ideia e as palavras-chave do Gherkin nas definições de suas demandas no software de gerenciamento de projetos que sua empresa já usa.

Palavras-chave

A lista abaixo apresenta as palavras-chave do Gherkin com uma breve descrição sobre seu objetivo

Feature: Descreve em níveis mais altos o propósito da funcionalidade e agrupa os diferentes cenários que podem existir;
Background: É o contexto, um conjunto inicial de steps que se repetem em todos os cenários da feature;
Scenario ou Example: Descreve um exemplo concreto sobre a regra de negócio e é ou não seguido por steps, é possível incluir quantos steps desejar;
Scenario Outline: Usado para descrever um cenário que se repete alterando as entradas e saídas;
Examples: Usado para construir um conjunto de exemplos de entrada e saída para usar dentro do Scenario Outline;
Step Given: Descreve a condição inicial do cenário;
Step When: Descreve um evento que normalmente causa uma mudança;
Step Then: Descreve o resultado esperado após o evento;
Step And: Pode ser usado para concatenar de forma positiva sentenças dos steps anteriores;
Step But: Pode ser usado para acrescentar uma negativa de forma subsequente a um dos steps superiores;

Casos de testes escritos com Gherkin

Para entendermos melhor a diferença entre simplesmente escrever a funcionalidade e escrevê-la usando Gherkin, que tal observamos um exemplo simples de login de usuário escritos das duas maneiras?

Simplesmente descrevendo:
Quando eu acessar o site e ir até a página de login e preencher o login a senha e clicar no botão de iniciar sessão, uma requisição a api do site deve ser feita transmitindo os dados preenchidos, se o resultado enviado pela api for positivo, uma mensagem de login efetuado com sucesso deve ser apresentada e o site deve me redirecionar para a página inicial do site mantendo minha sessão na memória do navegador.

Usando o Gherkin:

Feature: Login de usuário

  Scenario: Login de usuário válido
    Given que o usuário possua uma conta no site
    And acesse a página de login
    And preencha corretamente os dados de acesso
    When ele acionar o botão de entrar no sistema
    Then uma mensagem de sucesso deve ser apresentada
    And ele deve ser direcionado logado a página inicial do site

Como se pode observar, o modelo escrito com Gherkin é muito mais claro e omite qualquer detalhe técnico do desenvolvimento. Que tal darmos uma olhada em outro exemplo, agora usando as palavras-chave faltantes?

Feature: Café da tarde

Background:
  Given que os escritores de artigos sentem fome

Scenario Outline: Comendo fatias de bolo
  Given que existe <inicial> fatias de bolo
  When for comido <comido> fatias de bolo
  Then deve restar <restante> fatias de bolo

  Examples:
    | inicial | comido | restante |
    |    10   |    3   |     7    |
    |     5   |    5   |     0    |

Apesar dos exemplos modestos, acredito que seja possível compreender a ideia geral. Alguém poderia dizer que esse modelo adiciona mais trabalho na escrita dos cenários, ou mesmo que essa divisão parece infantil e que um texto corrido teria o mesmo efeito. Qualquer quantia de tempo acrescido na criação das descrições das atividades seria recuperada, uma vez que seria poupando tempo de manutenção e correções por conta do desentendimento quanto ao objetivo da função. Quanto a divisão parecer infantil, pense que você está escrevendo cenários para pessoas que não tem o mesmo conhecimento de negócio que você, imagine aquele marciano na sua frente e tente explicar para ele o que precisa ser feito...

Conclusão

Escrever os cenários com Gherkin é incrivelmente simples, o fato de ter poucas palavras-chave torna o modelo muito fácil de ser aprendido, e após escrever poucos cenários não é mais necessário pesquisar exemplos para se basear.

Além de ser fácil, esse modelo fornece uma estrutura de escrita que quando é bem usada, diminui consideravelmente os ruídos e mal-entendidos entre o que o solicitante precisar e o que é implementado de fato.

Por hoje é tudo pessoal, espero que tenham se divertido com a leitura e tenham se interessado por aprender um pouco mais sobre Gherkin, não deixe de conferir as fontes deste material.

Ah, e se encontrar um alien por aí, diga que eu mandei um "Oi!".

Fontes:

https://cucumber.io/docs/gherkin/reference/

https://medium.com/revista-tspi/gherkin-o-dia-em-que-entendi-que-estava-escrevendo-errado-220a84520819