DEV Community: Bruno Santos

Claude Opus 4.8: agentic coding benchmarks, Fast mode repricing, and new agentic capabilities

Bruno Santos — Fri, 29 May 2026 18:56:53 +0000

Anthropic released Claude Opus 4.8 on May 28, 2026. The model is available immediately on the Claude API (claude-opus-4-8), Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry. The announcement is dense with benchmark numbers and brings concrete changes for teams using the API or Claude Code in code automation workflows.

Agentic coding benchmarks

The most prominent number in the announcement is the agentic coding benchmark: 69.2% for Opus 4.8, versus 64.3% for Opus 4.7 and 58.6% for GPT-5.5. On OSWorld-Verified, an agentic computer-use benchmark, the model scores 83.4%. On GDPval-AA, which measures general quality on agentic tasks, the score is 1890 versus 1769 for GPT-5.5.

Anthropic also states that Opus 4.8 is 4x less likely than Opus 4.7 to miss code flaws that the model itself produced. If this holds in real use, it has a direct implication for assisted code review: a model that catches more of its own errors reduces the human review burden in subsequent steps.

As always with benchmarks, the relevant question for the team is whether the benchmark tasks are representative of your actual work. SWE-bench style benchmarks measure issue resolution on open-source repositories. If your work differs (data pipelines, legacy systems, internal API integrations), the 4.9 percentage point gap may be larger or smaller in practice.

Fast mode: speed and cost

Opus 4.8 keeps standard pricing at $5/$25 per million input/output tokens, same as Opus 4.7. Fast mode changes: it runs 2.5x faster and is priced at $10/$50, a 3x reduction from the previous Fast mode pricing.

This combination (faster and cheaper than the previous Fast) is relevant for pipelines processing high volumes. Lower latency matters in streaming scenarios or chained calls where response time accumulates. The price reduction on Fast changes the cost calculus for teams already using the previous mode and may open it up for cases where cost was the blocker.

Claude Code: parallel subagents and effort control

Two new capabilities in Claude Code are worth attention for teams using it on engineering tasks.

The first is dynamic workflows with parallel subagent execution. Claude Code can now break large-scale tasks (codebase migrations, audits, full test suite generation) into multiple subagents running in parallel. This changes the time profile for tasks that were previously necessarily sequential.

The second is effort control. Users can select Low, Medium, High (default), or Max to control how much computational thinking the model applies per task. For simple tasks, a lower level may be sufficient and faster. For complex tasks, Max ensures the most extensive reasoning available.

Messages API changes

Two changes in the Messages API affect existing agent architectures.

The first: system entries can now be inserted mid-conversation, not just at the start. This expands the prompt patterns available. Architectures that currently need to close and restart a conversation to inject new system instructions can simplify that flow.

# Before: system only at conversation start
messages = [
    {"role": "user", "content": "run the analysis"}
]

# Now: system can appear mid-conversation
messages = [
    {"role": "user", "content": "run the analysis"},
    {"role": "assistant", "content": "..."},
    {"role": "system", "content": "new context or instruction"},
    {"role": "user", "content": "continue"}
]

The second: tool-calling was updated to complete tasks using fewer steps. For workflows that make many sequential tool calls, this can reduce the number of roundtrips and the total cost of the interaction.

What to evaluate

Opus 4.8 is an incremental update with measurable improvements in specific areas. For teams already using Opus 4.7, it makes sense to compare performance on your actual tasks, not just on benchmarks. The repriced Fast mode may change the cost calculation for high-volume pipelines. The Messages API changes are the most immediately adoptable and can simplify existing architectures with minimal refactoring.

How is your team using Claude Code or the API for code automation? Do the agentic coding improvements translate to the tasks you work on?

Fonte: Claude Opus 4.8

Fragments May 27: on-the-loop with Claude Code, 2h of endurance, and NHS closing repos

Bruno Santos — Fri, 29 May 2026 10:00:00 +0000

Martin Fowler's May 27 Fragments brings together four arguments with direct implications for teams working with AI agents. All four are worth covering.

Ian Johnson: build quality gates before releasing the agent

Ian Johnson published a series about restructuring a gnarly codebase: three months, 258 commits, moving from a Laravel monolith with no tests to an application with automated quality gates and an AI agent shipping production code with minimal supervision.

The insight Fowler highlights is about the transition from in-the-loop to on-the-loop:

"For the first two months of this project, I used Claude Code with auto-approve turned off. Every file edit, every terminal command, every change… I reviewed it before it executed. The results were good. The code was clean. But I was doing most of the thinking and half the typing. The agent was a fancy autocomplete with better suggestions."

Ian Johnson

Manual review of every change is not how you build trust in the agent. Trust comes from building the structure that ensures the agent will do the right thing, then stepping back. The sequence: characterization tests first, static analysis, architectural patterns that make things flow correctly. Fowler notes this is exactly the sequence he would use himself.

Adam Tornhill: roughly 2 hours of cognitive endurance

Adam Tornhill observes that agentic work has a decision density that is mentally more expensive than it appears. The estimate is roughly two hours as a sustainable limit, not a full day of work.

The implication: adding more parallel agents does not solve the problem, because the bottleneck is the coordinating engineer's cognitive capacity, not available processing volume. The solutions are smaller tasks, automation, and verification mechanisms, not more parallelism.

NHS: closing open source repositories

NHS (UK National Health Service) closed open source repositories citing LLM threats to code security. The UK Government Data Services countered directly: making code private reduces scrutiny and coordination without eliminating the underlying vulnerabilities. Private code obscures the problem, it does not solve it.

Economic impact: the data that will get worse before it gets better

Labor market data shows graduates with high AI exposure experience a 6.6% employment drop versus 1.5% among less-exposed peers. The historical argument that major technological advances rarely cause long-term unemployment exists, but current data points in a different direction. Fowler's hypothesis is that the full consequences will likely only be visible during a recession.

For leadership teams, the four points have distinct practical implications. Johnson's sequence is an adoption framework. Tornhill's endurance limit is a sprint planning criterion. The NHS posture is a security case to study. The economic data is context that will remain relevant across the next few planning cycles.

Fonte: Fragments: May 27

Magnifica Humanitas: what the first AI encyclical says for engineers

Bruno Santos — Thu, 28 May 2026 13:31:06 +0000

In May 2026, Pope Leo XIV published Magnifica Humanitas: On Safeguarding the Human Person in the Time of Artificial Intelligence. At 235 pages, it is the first papal document dedicated entirely to AI. The approach is principles-based, with no prescriptive technical rules or bans on specific technologies.

For engineers building AI systems, the document is relevant as an institutional reference: its accountability framework may shape regulation in Catholic-majority countries and offers a structure for internal AI governance discussions.

The core structure: who answers for what

The most operationally relevant point in the document is its distribution of responsibility. The text explicitly names four categories of actors: those who design the technology, those who finance it, those who regulate it, and those who use it.

The framing is direct: "Technology is never neutral, because it takes on the characteristics of those who devise, finance, regulate, and use it." In other words, the document argues that technological neutrality does not exist in practice, because technology is produced by people with distinct interests, contexts, and power.

This distribution of responsibility is useful as a checklist for internal discussions. When a team decides how to deploy an AI system, which of the four categories is best represented in the conversation? Design is usually present. Financing sometimes. Regulation and users often not.

What the document recognizes and what it delimits

In paragraph 9, the text acknowledges that technology can "heal, connect, educate and protect" but also "divide, exclude and generate injustice." The distinction, according to the text, depends on who controls it and how.

In paragraph 233, the text delimits what computational systems cannot replace: "No computational system can create a heart that gives itself, or a conscience that discerns good from evil." The document does not argue that AI is inherently good or bad, but that certain human capacities, specifically moral judgment, cannot be delegated to computational systems.

This has a practical implication: decisions involving moral judgment (who receives credit, who passes medical screening, who is flagged as a security risk) cannot be fully automated without someone remaining accountable for them.

The historical context: continuation of Rerum novarum

The document deliberately marks the 135th anniversary of Rerum novarum, the 1891 encyclical on industrial labor conditions. The continuity is intentional.

In 1891, the Church responded to the transformation brought by industrialization with a document on labor rights and human dignity. In 2026, the document responds to the transformation driven by AI with the same framing: the central question is not the technology itself, but how human responsibility is distributed when it transforms the conditions of life and work.

For teams following AI governance debates, this context matters. Magnifica Humanitas positions the Church in continuity with a 135-year tradition of reflection on technological transformation and work, which gives the document different institutional weight than a one-time statement.

Tracking how the text's principles translate into concrete policy in countries where the Church has regulatory influence is prudent for teams operating in those markets.

Fonte: Magnifica Humanitas. Vatican (official text)

The pattern of forwarding AI responses without review, and what it means for engineering teams

Bruno Santos — Thu, 28 May 2026 12:26:00 +0000

A post at orchidfiles.com documents a pattern worth thinking about: people using AI as an intermediary in responses, forwarding generated content without critical review. For engineering teams that rely on technical exchanges in forums, code reviews, and support tickets, this has practical implications.

What the post documents

The author describes three concrete situations.

First, while looking for help with malicious GitHub repositories, they found the same AI-generated response copied verbatim across multiple discussion threads. No one had apparently read what they were posting.

Second, a client answered technical questions by forwarding ChatGPT screenshots. The content had no clear connection to the original question. The same behavior repeated in the same conversation, without the client reviewing what they were sending.

Third, after several exchanges on Reddit, the author realized they had been talking to an AI agent, not a person.

The post's core observation:

"I'm tired of talking to AI. I want to talk to real people. But even when I talk to people, they forward my questions to AI and send me the AI's answer."

— orchidfiles.com

The issue isn't AI use itself. It's the absence of critical review before passing along the output.

Why this matters in technical contexts

In engineering environments, technical exchanges carry more weight than casual conversation. An incorrect response in an internal forum can influence architectural decisions. An unreviewed response in a support ticket can send someone down hours of debugging based on a wrong premise. A copied response in a code review can pass through multiple reviewers without anyone questioning its source.

The problem compounds because AI output often looks well-formed. Surface-level writing quality is not a signal of technical correctness, but it can be read that way by whoever receives the response.

What engineering teams can establish

The question isn't whether to use AI tools, but whether to establish review practices before forwarding outputs.

Some practices worth considering:

Review generated content before sharing, especially in technical channels where the response may influence decisions
Indicate when a response was AI-generated or AI-assisted, so the recipient can calibrate appropriately
Treat AI outputs as drafts that need review, not ready-to-send answers

These norms don't need to be formal or bureaucratic. A brief team alignment on how to use AI tools in technical exchanges can be enough to shift the pattern.

It is worth looking at which channels this pattern already appears in: internal forums, code reviews, tickets, client conversations. How aware is your team of this, and what makes sense to address?

Fonte: I'm Tired of Talking to AI

'Verified' changed meaning: what agentic engineering demands from development teams

Bruno Santos — Thu, 28 May 2026 12:24:05 +0000

In the April 29 Fragments, Martin Fowler linked three articles on agentic programming that arrive at the same conclusion. The investment that matters is not in code generation speed, but in verification, harness, and code legibility for agents.

What Chris Parsons says about 'verified'

The most direct contribution is from Chris Parsons, in his third update of 'Coding with AI'. The core argument: the concept of "verified" had to evolve alongside the throughput of AI agents.

Parsons writes: "'Verified' used to mean 'read by you'. With modern agent throughput, it has to mean 'checked by tests, by type checkers, by automated gates, or by you where your judgement matters'. The check still happens; it just does not always happen in your head."

Verification did not disappear. It migrated from human reading to automated tooling when the volume generated by agents outpaced individual review capacity. This is not a degradation of the process: it is a necessary adaptation.

Parsons also distinguishes two modes of AI use in development. Vibe coding is generating code without looking at it, without taking responsibility for the structure. Agentic engineering is when the engineer remains responsible for quality and AI is a tool in the process, not a replacement for the engineer.

On the senior engineer's role in this context, Parsons writes: "The way out is to train the AI so the diffs are right the first time, to make yourself the person on the team who shapes the harness, and to make that work the visible thing you are measured on."

Harness Engineering as a verification layer

Birgitta Böckeler, in an article published on martinfowler.com in discussion with Chris Ford, develops the concept of Harness Engineering. The central idea: computational sensors (tests, static analysis, type checkers) improve AI-generated code quality more reliably than human review.

Böckeler writes: "LLMs are great for exploratory and fuzzy rules, but once you have something objective, converting it to formal, unambiguous, deterministic format can give more assurance." When a quality rule becomes objective and deterministic, formalizing it in code (as a test or a type) provides more assurance than relying on human review to catch it.

The practical point: before optimizing prompts for the agent, verify whether the verification harness can detect the problems the agent might introduce. A weak harness means better prompts just produce more sophisticated bugs.

Identifiers and LLM performance

The third article is from Adam Tornhill on the impact of function length on LLM-generated code quality. The relevant point: LLMs rely heavily on names, structure, and local context to infer meaning. When meaningful identifiers are replaced with arbitrary names, model performance drops significantly.

This has a direct implication for teams using agents to work on legacy code with inconsistent naming. The quality of the agent's output is partly a function of the quality of identifiers in the input code.

What the three articles have in common

All three converge on the same thesis: in agentic programming, the competitive edge is not in generating faster. It is in review surfaces that scale, a robust harness, and code structured so the agent can reason about it accurately.

The right decision depends on where the actual bottleneck is in your process: if generation is the bottleneck, improving prompts makes sense. If verification is the bottleneck, investing in harness has higher returns.

Fonte: Fragments: April 29. Martin Fowler

Magnifica Humanitas: what the first AI encyclical says for engineers

Bruno Santos — Thu, 28 May 2026 12:19:55 +0000

The core structure: who answers for what

What the document recognizes and what it delimits

The historical context: continuation of Rerum novarum

The document deliberately marks the 135th anniversary of Rerum novarum, the 1891 encyclical on industrial labor conditions. The continuity is intentional.

Tracking how the text's principles translate into concrete policy in countries where the Church has regulatory influence is prudent for teams operating in those markets.

Fonte: Magnifica Humanitas. Vatican (official text)

Magnifica Humanitas: o que a primeira encíclica sobre IA diz para engenheiros

Bruno Santos — Thu, 28 May 2026 10:00:00 +0000

Em maio de 2026, o Papa Leão XIV publicou Magnifica Humanitas: On Safeguarding the Human Person in the Time of Artificial Intelligence. Com 235 páginas, é o primeiro documento papal dedicado inteiramente ao tema da IA. A abordagem é baseada em princípios, sem prescrições técnicas ou proibições de tecnologias específicas.

Para engenheiros que constroem sistemas de IA, o documento é relevante como referência institucional: sua estrutura de accountability pode influenciar regulação em países de maioria católica e oferece um framework para discussões internas sobre governança.

A estrutura central: quem responde por quê

O ponto mais operacionalmente relevante do documento é sua distribuição de responsabilidade. O texto nomeia explicitamente quatro categorias de atores: quem projeta a tecnologia, quem a financia, quem a regula, e quem a usa.

A formulação é direta: "Technology is never neutral, because it takes on the characteristics of those who devise, finance, regulate, and use it." Em outras palavras, o documento argumenta que a neutralidade tecnológica não existe na prática, porque tecnologia é produzida por pessoas com interesses, contextos e poderes distintos.

Essa distribuição de responsabilidade é útil como checklist para discussões internas. Quando um time decide como implantar um sistema de IA, qual das quatro categorias é mais representada na conversa? Design geralmente está presente. Financiamento às vezes. Regulação e uso frequentemente não.

O que o documento reconhece e o que delimita

No parágrafo 9, o texto reconhece que a tecnologia pode "curar, conectar, educar e proteger", mas também "dividir, excluir e gerar injustiça". A distinção, segundo o texto, depende de quem controla e como.

No parágrafo 233, o texto delimita o que sistemas computacionais não substituem: "No computational system can create a heart that gives itself, or a conscience that discerns good from evil." Ou seja, o documento não propõe que IA é inerentemente boa ou má, mas que certas capacidades humanas, especificamente julgamento moral, não são delegáveis a sistemas computacionais.

Isso tem implicação prática: decisões que envolvem julgamento moral (quem recebe crédito, quem passa por triagem médica, quem é sinalizado como risco de segurança) não podem ser completamente automatizadas sem que alguém responda por elas.

O contexto histórico: continuação de Rerum novarum

O documento marca deliberadamente o 135º aniversário da Rerum novarum, a encíclica de 1891 sobre as condições do trabalho industrial. A continuidade não é acidental.

Em 1891, a Igreja respondeu à transformação provocada pela industrialização com um documento sobre direitos do trabalho e dignidade humana. Em 2026, o documento responde à transformação provocada pela IA com o mesmo enquadramento: a questão central não é a tecnologia em si, mas como a responsabilidade humana é distribuída quando ela transforma as condições de vida e trabalho.

Para times que acompanham debates sobre governança de IA, esse contexto importa. A Magnifica Humanitas posiciona a Igreja em continuidade com uma tradição de 135 anos de reflexão sobre transformações tecnológicas e trabalho, o que dá ao documento um peso institucional diferente de uma declaração pontual.

Acompanhar como os princípios do texto se traduzem em políticas concretas nos países onde a Igreja tem influência regulatória é prudente para equipes que operam nesses mercados.

Fonte: Magnifica Humanitas. Vatican (official text)

O padrão de repassar respostas de IA sem revisão e o que isso significa para times de engenharia

Bruno Santos — Wed, 27 May 2026 15:30:00 +0000

Neste conteúdo, vamos analisar um padrão descrito em orchidfiles.com: o uso de IA como intermediário nas respostas humanas, onde o conteúdo gerado é repassado sem revisão crítica. O padrão tem implicações práticas para times de engenharia que dependem de trocas técnicas em fóruns, code reviews e chamados de suporte.

O que o post documenta

O autor descreve três situações concretas.

Na primeira, ao buscar ajuda sobre repositórios maliciosos no GitHub, encontrou a mesma resposta de IA copiada verbatim em múltiplas discussões do problema. Nenhum dos participantes aparentemente havia lido o que estava postando.

Na segunda, um cliente respondeu perguntas técnicas enviando prints de ChatGPT com informações sem relação com a questão original. O comportamento se repetiu na mesma conversa, sem revisão do conteúdo.

Na terceira, o autor trocou várias mensagens no Reddit antes de perceber que estava interagindo com um agente de IA.

O texto resume o padrão assim:

"I'm tired of talking to AI. I want to talk to real people. But even when I talk to people, they forward my questions to AI and send me the AI's answer."

— orchidfiles.com

Ou seja, a questão central não é o uso de IA em si, mas a ausência de revisão crítica antes de repassar o output.

Por que isso importa em contextos técnicos

Em ambientes de engenharia, as trocas técnicas têm peso diferente de uma conversa informal. Uma resposta incorreta em um fórum interno pode influenciar decisões de arquitetura. Uma resposta não revisada em um chamado de suporte pode gerar horas de debugging em cima de uma premissa errada. Uma resposta copiada em um code review pode passar por múltiplos reviewers sem que ninguém questione a origem.

O problema se amplifica porque o output de IA frequentemente tem a aparência de texto bem formulado. A qualidade superficial da escrita não é um sinal de correção técnica, mas pode ser lida como tal por quem recebe a resposta.

O que times de engenharia podem estabelecer

A questão não é proibir o uso de ferramentas de IA, mas estabelecer normas de revisão antes de repassar outputs.

Algumas práticas que fazem sentido considerar:

Revisar o conteúdo gerado antes de compartilhar, especialmente em canais técnicos onde a resposta pode influenciar decisões
Indicar quando uma resposta foi gerada ou assistida por IA, para que o receptor possa calibrar o nível de confiança adequado
Tratar outputs de IA como rascunhos que precisam de revisão, não como respostas prontas para envio

Essas normas não precisam ser formais ou burocráticas. Uma conversa de alinhamento no time sobre como usar ferramentas de IA nas trocas técnicas pode ser suficiente para mudar o padrão.

Devemos analisar em quais canais esse padrão já aparece nas nossas interações: fóruns internos, code reviews, chamados, conversas com clientes. O quanto o time já está ciente disso e o que faz sentido ajustar?

Fonte: I'm Tired of Talking to AI

'Verified' mudou de significado: o que agentic engineering exige de times de desenvolvimento

Bruno Santos — Wed, 27 May 2026 12:00:00 +0000

Nos Fragments de 29 de abril, Martin Fowler reuniu três artigos sobre programação agentiva que chegam à mesma conclusão. O investimento que importa não está em velocidade de geração de código, mas em verificação, harness e legibilidade do código para agentes.

O que Chris Parsons diz sobre 'verified'

A contribuição mais direta é de Chris Parsons, em sua terceira atualização do guia 'Coding with AI'. O argumento central é que o conceito de "verified" precisou evoluir junto com o throughput dos agentes de IA.

"'Verified' used to mean 'read by you'. With modern agent throughput, it has to mean 'checked by tests, by type checkers, by automated gates, or by you where your judgement matters'. The check still happens; it just does not always happen in your head."

— Chris Parsons

Em outras palavras, a verificação não deixou de existir. Ela migrou de leitura humana para ferramentas automatizadas quando o volume gerado por agentes superou a capacidade de revisão individual. Isso não é uma degradação do processo: é uma adaptação necessária.

Parsons também distingue dois modos de uso de IA no desenvolvimento. Vibe coding é quando você gera código sem olhar, sem se responsabilizar pela estrutura. Agentic engineering é quando o engenheiro continua responsável pela qualidade e a IA é uma ferramenta no processo, não um substituto do engenheiro.

"The way out is to train the AI so the diffs are right the first time, to make yourself the person on the team who shapes the harness, and to make that work the visible thing you are measured on."

— Chris Parsons

Harness Engineering como camada de verificação

Birgitta Böckeler, em artigo publicado no martinfowler.com em discussão com Chris Ford, desenvolve o conceito de Harness Engineering. A ideia central: sensores computacionais (testes, análise estática, type checkers) aumentam a qualidade do código gerado por IA de forma mais confiável do que revisão humana.

"LLMs are great for exploratory and fuzzy rules, but once you have something objective, converting it to formal, unambiguous, deterministic format can give more assurance."

— Birgitta Böckeler

Ou seja, quando uma regra de qualidade se torna objetiva e determinística, formalizá-la em código (como um teste ou um tipo) oferece mais garantia do que depender de revisão humana para capturá-la.

O ponto prático: antes de otimizar prompts para o agente, vale verificar se o harness de verificação consegue detectar os problemas que o agente pode introduzir. Um harness fraco significa que melhores prompts apenas produzem bugs mais sofisticados.

Identificadores e performance do LLM

O terceiro artigo é de Adam Tornhill sobre o impacto do tamanho de funções na qualidade do código gerado por LLMs. O ponto relevante: LLMs dependem fortemente de nomes, estrutura e contexto local para inferir significado. Quando identificadores significativos são substituídos por nomes arbitrários, a performance do modelo cai de forma significativa.

Isso tem implicação direta para times que usam agentes para trabalhar em código legado com nomenclatura inconsistente. A qualidade do output do agente é, em parte, função da qualidade dos identificadores no código de entrada.

O que os três artigos têm em comum

Os três convergem para a mesma tese: em programação agentiva, o diferencial não está em gerar mais rápido. Está em review surfaces que escalam, harness robusto e código estruturado de forma que o agente possa raciocinar sobre ele com precisão.

Devemos analisar onde está o gargalo real do nosso processo antes de decidir onde investir: se o gargalo é geração, melhorar prompts faz sentido. Se é verificação, investir em harness tem retorno maior.

Fonte: Fragments: April 29. Martin Fowler

Automatizando geração de logs com Delegating Handler em .NET

Bruno Santos — Fri, 11 Aug 2023 13:09:25 +0000

Neste artigo vamos entender como funciona um Deleganting Handler e como podemos utilizá-lo para interceptar requisições e respostas Http e deixar de forma transparente o processo de geração de logs.

Delegating Handler

Um Delegating Handler funciona de forma similar a um filtro, onde através dele é possível interceptar requisições e respostas Http e então implementar uma lógica personalizada. Também é possível encadear vários Delegating Handlers criando uma pipeline que irá executar as lógicas personalizadas antes de serem enviadas ou recebidas pelo cliente ou servidor.

Automatizando Logs

Como foi visto, um Delegating Handler pode ser utilizado em diversos cenários no nosso dia a dia, efetuando a interceptação de requisições e respostas Http.

Abaixo iremos demonstrar como podemos fazer isso de forma rápida e fácil.

O primeiro passo é efetuar a criação de uma classe que herde de DelegatingHandler. Iremos utilizar o ILogger para efetuar a geração dos nossos logs.

public class LogDelegatingHandler : DelegatingHandler
{
    private readonly ILogger<LogDelegatingHandler> _logger;

    public LogDelegatingHandler(ILogger<LogDelegatingHandler> logger)
    {
        _logger = logger;
    }

    public LogDelegatingHandler(HttpMessageHandler innerHandler, ILogger<LogDelegatingHandler> logger) : base(innerHandler)
   {
        _logger = logger;
   }    
}

O próximo passo é efetuar o override do método SendAsyncpara que possamos interceptar o request e o response e implementar a nossa lógica personalizada.

protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
    string requestBody = null;
    string responseBody = null;

    if (request.Content != null) 
    {
        requestBody = await request.Content.ReadAsStringAsync();
    }

    _logger.LogDebug("Http request body is {requestBody}.", requestBody);

    var response = await base.SendAsync(request, cancellationToken);

    if (response.Content != null)
    {
        responseBody = await response.Content.ReadAsStringAsync();
    }

    _logger.LogDebug("Http response body is {responseBody}.", responseBody);

    return response;
}

Para que o nosso Delegating Handler possa ser facilmente utilizado, devemos então efetuar o seu registro e referenciar o seu uso nos serviços que necessitem da geração desses logs.

   static IHostBuilder CreateHostBuilder(string[] args) =>
     Host.CreateDefaultBuilder(args)
       .ConfigureAppConfiguration(app =>
       {
           app.AddJsonFile("appsettings.json");
           app.AddEnvironmentVariables();
       })
       .ConfigureServices((_, services) =>
       {
           services
               .AddTransient<LogDelegatingHandler>();

           services
               .AddTransient<ICepService, CepService>()
               .AddHttpClient("cepService")
               .AddHttpMessageHandler<LogDelegatingHandler>();
       })
       .UseSerilog((builder, configuration) =>
       {
           configuration.ReadFrom.Configuration(builder.Configuration);
       });

Com isso toda requisição Http que for feita no serviço informado será interceptada por nosso LogDelegatingHandler e terá os logs gerados.

Conclusão

O exemplo acima é apenas uma demonstração do que podemos fazer com o Delegating Handler. O objetivo foi apenas exemplificar o seu uso tornando a geração de logs mais transparente. Melhorias como a possibilidade de definição do nível de log podem ser implementadas.

Espero que tenham gostado do artigo, qualquer feedback é bem vindo.

Em breve voltarei com um outro exemplo de como podemos criar um Delegating Handler para automatizar o fluxo de autenticações.

Este exemplo está disponibilizado no GitHub:

Logs Automáticos com Delegating Handler

Referências

Delegating Handler | Microsoft Learn

TTL em documentos com MongoDB

Bruno Santos — Fri, 11 Aug 2023 12:40:15 +0000

O objetivo deste artigo é a demonstração de como podemos inserir documentos com tempo de vida (TTL — Time to Live ) no MongoDB.

Em alguns cenários a criação de documentos com tempo de vida pode ser necessário, como por exemplo, registros de logs ou de eventos. Em alguns bancos para efetuar a limpeza desses documentos seria necessário a criação de uma rotina para efetuar a exclusão desses dados após um determinado tempo. No MongoDB podemos utilizar os índices TTL para efetuar a exclusão automática desses dados.

Índices

Os índices são uma das ferramentas de otimização mais conhecidas e utilizadas para otimização de acesso, através dele o número de documentos a serem inspecionados passa a ser menor.

Para uma consulta mais detalhada sobre índices e seus tipos no MongoDB, podemos utilizar sua documentação disponível em Índices - MongoDB.

Índices TTL

De acordo com a documentação do MongoDB, índices TTL são índices especiais de campo único que são usados para remover automaticamente documentos de uma coleção após uma determinada quantidade de tempo ou em um horário de relógio específico.

Criando um índice TTL

Para efetuar a criação de um índice TTL no MongoDB vamos utilizar como modelo a estrutura abaixo.

public class EventLog
{
    public string Name { get; set; }
    public string Description { get; set; }
    public string UserName { get; set;}
    public DateTime Date { get; set; }
    public DateTime Expiration { get; set; }
}

A partir do modelo acima, ao inserir um documento no Mongo vamos utilizar o campo **Expiration **como chave a ser utilizada para a exclusão automática.

O script abaixo é responsável pela criação do índice TTL na coleção eventLog.

db.eventlog
  .createIndex( { "Expiration": 1 }, { expireAfterSeconds: 30} )

Abaixo temos o documento que será persistido no nosso banco.

{
    "Name" : "Event Log 123",
    "Description" : "Description event log",
    "UserName" : "BH",
    "Date" : ISODate("2023-04-26T19:00:00.00+0000"),
    "Expiration" : ISODate("2023-04-26T20:00:00.00+0000"),
}

Comportamento

A expiração do documento ocorrerá após o número específico de segundos ter passado desde o valor do campo indexado, no nosso caso o valor do campo **Expiration + valor de expireAfterSeconds **utilizado na criação do index.

Para o exemplo de índice e registro que criamos, a expiração do registro iria ocorrer após as “2023–04–26T20:00:30.00+0000”.

Informações adicionais

Podemos criar um índice com o campo **expireAfterSeconds **igual a 0, com isso o documento terá sua expiração logo após o horário atual ser igual ao campo do documento utilizado como referência.

Se o campo for uma matriz que contenha mais valores do tipo data, será utilizado o menor valor como parâmetro para calcular o limite de expiração.

Se o campo do documento não for uma data ou uma matriz que contenha um ou mais valores do tipo data, o documento não será excluído.

Referências

Indexes - MongoDB Manual
Índices TTL - MongoDB

C# — Operadores implícitos e explícitos

Bruno Santos — Fri, 11 Aug 2023 00:27:08 +0000

Neste conteúdo, vamos falar sobre operadores implícitos e explícitos em C# e como podemos criar os nossos próprios operadores.

Operadores explícitos

A conversão explícita ocorre quando a conversão de um tipo de dado em outro não é possível de forma direta, sendo então necessário especificar a conversão de maneira explícita no código (cast). Esse tipo de conversão pode resultar na perda de informações ou dados truncados.

double x = 1.77;
int y = (int)x;

No exemplo acima, não é possível realizar a conversão de forma natural do tipo doublepara int, sendo necessário realizar o cast. No exemplo acima teremos perda de dados ao converter o tipo double **para **int.

Operadores implícitos

São aqueles onde o compilador possui a capacidade de converter um determinado tipo de dado em outro sem a necessidade de uma conversão explícita (cast). Na conversão implícita não há perda de dados.

int x = 2023;
double y = x;

No exemplo acima foi possível realizar a conversão de x, do tipo **int **para **double **de forma natural. Vale lembrar que números reais suportam números inteiros.

Sobrecarga de operadores

O C# permite a criação de operadores explícitos e implícitos, porém não é possível redefinir um operador já existente.

public static explicit operator ObjetoDestino(ObjetoOrigem origem)
{
     // lógica de conversão
}

public static implicit operator ObjetoDestino(ObjetoOrigem origem)
{
     // lógica de conversão
}

Definindo um operador explícito

Vamos utilizar como exemplo a conversão entre as unidades grama e quilograma. Abaixo temos a definição das classes e a criação do nosso operador explícito na classe Grama que possui a lógica de conversão para Quilograma.

public class Grama
{
    public int Peso { get; set; }

    public Grama(int peso)
    {
        Peso = peso;
    }

    public static explicit operator Quilograma(Grama grama)
    {
        int peso = grama.Peso / 1000;
        return new Quilograma(peso);
    }
}

public class Quilograma
{
    public int Peso { get; set; }

    public Quilograma(int peso)
    {
        Peso = peso;
    }
}

// Como usar

Grama pesoEmGrama = new Grama(2500);
Quilograma pesoEmQuilograma = (Quilograma)pesoEmGrama;

Definindo um operador implícito

Operadores de conversões implícitas podem ser utilizados, por exemplo, em cenários de conversões de DTOs ou ViewModels para classes do nosso domínio sem a utilização de ferramentas externas como por exemplo o AutoMapper. Abaixo um exemplo de conversão implícita entre nosso DTO e nossa classe de domínio.

public class PessoaDto
{
    public string Nome { get; set; }
    public int Idade { get; set; }
    public string Email { get; set; }

    public static implicit operator Pessoa(PessoaDto pessoa)
    {
        return new Pessoa(pessoa.Nome, pessoa.Idade, pessoa.Email);
    }    
}

public class Pessoa
{
    public Guid Id { get; set; }
    public string Nome { get; set; }
    public int Idade { get; set; }
    public string Email { get; set; }

    public Pessoa(string nome, int idade, string email)
    {
        Id = Guid.NewGuid();
        Nome = nome;
        Idade = idade;
        Email = email;
    }
}

// Como usar

PessoaDto pessoaDto = new PessoaDto()
{
    Email = "contato@medium.com",
    Idade = 25,
    Nome = "Fulano"
};

Pessoa pessoa = pessoaDto;

No exemplo acima podemos efetuar a conversão do nosso DTO em nossa classe de domínio de forma natural.

Conclusão

A sobrecarga de operadores implícitos e explícitos é um recurso poderoso que pode tornar nossos códigos mais expressivos e fáceis de usar, porém nada está escrito em pedra e nenhuma solução é ideal para todos os projetos. Devemos sempre analisar o cenário, como o time trabalha, além de levantar os impactos que podem surgir em sua adoção.

Fontes

Operadores de conversão explícitos e implícitos definidos pelo usuário