Forem: 👨‍💻 Lucas Silva

RabbitMQ: conceitos fundamentais

👨‍💻 Lucas Silva — Sun, 12 Jan 2025 19:41:53 +0000

O RabbitMQ é um dos message brokers mais populares, conhecido por sua flexibilidade e robustez no processamento de mensagens. Este artigo apresenta os principais conceitos do RabbitMQ, incluindo publishers, consumers, exchanges, filas e mecanismos de reconhecimento de mensagens.

Publisher/Producer

Uma aplicação publisher é responsável por publicar ou produzir mensagens. Além disso, uma aplicação que publica mensagens também pode consumi-las.

No RabbitMQ, uma mensagem publicada precisa ser roteada para uma fila. Se houver consumidores online conectados à fila, a mensagem será enviada diretamente para eles.

Consumer

Um consumer é uma aplicação que consome mensagens de uma fila e realiza o reconhecimento (acknowledgement) dessas mensagens. Da mesma forma que um publisher pode consumir mensagens, um consumer também pode publicá-las.

Exchanges

No RabbitMQ, as mensagens não são enviadas diretamente para as filas. Os publishers enviam mensagens para um exchange, que é responsável por rotear as mensagens para filas específicas, com base nas ligações (bindings) e chaves de roteamento (routing keys).

Tipos de Exchanges

Os exchanges são categorizados de acordo com a forma como realizam o roteamento de mensagens:

Direct: As mensagens são roteadas para filas cuja ligação (binding) coincida exatamente com a chave de roteamento (routing key).

Fanout: Roteia mensagens para todas as filas que estejam conectadas a ele.

Topic: Faz um match com base em padrões (wildcards) entre a chave de roteamento da mensagem e a chave de ligação das filas.

Headers: Roteia mensagens com base nos cabeçalhos especificados na mensagem.

Queues

As filas no RabbitMQ são coleções ordenadas de mensagens, e elas seguem uma lógica de First In, First Out (FIFO) para o enfileiramento e desenfileiramento. Cada mensagem é processada em ordem, garantindo consistência no consumo.

Acknowledgement

O acknowledgement é o mecanismo de confirmação de que uma mensagem foi entregue e/ou processada pelo consumidor. Ele permite que o RabbitMQ saiba quando pode marcar uma mensagem como concluída ou quando deve reenviar a mensagem.

Delivery Acknowledgement

Existem diferentes formas de reconhecimento no RabbitMQ, que determinam quando uma mensagem é considerada processada com sucesso:

Reconhecimento Automático: O RabbitMQ considera a mensagem processada assim que ela é entregue.
Reconhecimento Manual: Requer que o consumidor informe explicitamente o status da mensagem. Isso pode ser feito de forma positiva ou negativa:
- basic.ack: Usado para indicar que a mensagem foi processada com sucesso.
- basic.nack: Usado para indicar que o processamento falhou.
- basic.reject: Similar ao basic.nack, mas com limitações (não suporta múltiplas mensagens ao mesmo tempo).

Quando o reconhecimento negativo ocorre, a mensagem pode ser reenfileirada, roteada para um dead letter exchange, ou descartada, dependendo da configuração do campo requeue.

Dead Letter

Mensagens podem ser marcadas como dead-letter e republicadas caso algum dos seguintes eventos ocorra:

A mensagem é negativamente reconhecida por um consumidor.
A mensagem expira devido ao TTL (Time To Live).
A mensagem excede o limite de tamanho configurado.
A mensagem ultrapassa o limite de tentativas de entrega.

Dead letters permitem lidar com falhas de forma estruturada, garantindo maior resiliência no sistema.

Compreender esses conceitos é essencial para projetar sistemas de mensageria eficientes e confiáveis. O RabbitMQ oferece flexibilidade para adaptar-se a diversas arquiteturas, tornando-o uma ferramenta poderosa no ecossistema de aplicações distribuídas.

Referêcias

Documentação do RabbitMQ

Formulários com React Hook Form + Zod

👨‍💻 Lucas Silva — Thu, 07 Nov 2024 22:40:58 +0000

Introdução

Quando comecei a programar, precisava escrever bastante código em JavaScript puro para coletar dados de um formulário. De lá para cá, o desenvolvimento web evoluiu tanto que hoje temos bibliotecas que abstraem grande parte desse trabalho, facilitando a gestão dos dados dos formulários.

Neste artigo, vou mostrar como utilizar o React Hook Form para trabalhar com dados de formulários e zod para validar esses dados de forma eficiente e organizada.

Tô com pressa, me dê o código completo

Tá na mão:

import { Label } from '@/components/ui/label';
import { Input } from '@/components/ui/input';
import { Button } from '@/components/ui/button';
import { Gamepad, Gamepad2 } from 'lucide-react';
import { useForm } from 'react-hook-form';
import { z } from 'zod';
import { zodResolver } from '@hookform/resolvers/zod';
import { toast, Toaster } from 'sonner';

const signUpForm = z
  .object({
    name: z
      .string()
      .min(2, { message: 'Nome deve ter ao menos 2 caracteres' })
      .max(50, { message: 'Nome deve ter no máximo 50 caracteres' }),
    email: z.string().email().max(100, { message: 'E-mail deve ter no máximo 100 caracteres' }),
    password: z.string().max(100, { message: 'Senha deve ter no máximo 100 caracteres' }),
    confirm: z.string(),
  })
  .refine((data) => data.password === data.confirm, {
    message: 'Senhas não conferem!',
    path: ['confirm'],
  });

type SignUpForm = z.infer<typeof signUpForm>;

export function App() {
  const {
    handleSubmit,
    register,
    reset,
    formState: { isSubmitting, errors },
  } = useForm<SignUpForm>({
    resolver: zodResolver(signUpForm),
  });

  async function handleSignup(data: SignUpForm) {
    console.log(data);
    await new Promise((resolve) => {
      setTimeout(resolve, 2000);
    });
    reset();
    toast.success('Conta criada com sucesso!');
  }

  return (
    <>
      <Toaster richColors />
      <div className="min-h-screen lg:grid lg:grid-cols-2 antialiased gap-8">
        <div className="hidden lg:flex h-full justify-center border-r border-foreground/5 bg-foreground text-muted-foreground items-center gap-3 text-lg">
          <Gamepad2 />
          <span className="font-semibold">gamers.shop</span>
        </div>
        <div className="flex flex-col items-center justify-center gap-6 min-h-screen">
          <div className="px-10 w-96 h-full flex flex-col justify-center items-center lg:w-[500px]">
            <h1 className="flex items-center gap-2 mb-4 text-2xl font-semibold tracking-tight">
              <Gamepad />
              Crie sua conta
              <Gamepad />
            </h1>
            <form onSubmit={handleSubmit(handleSignup)} className="space-y-4 w-full ">
              <div className="space-y-2">
                <Label htmlFor="name">Nome</Label>
                <Input id="name" type="text" {...register('name')} />
                {errors.name && <span className="text-sm text-red-500">{errors.name.message}</span>}
                {}
              </div>
              <div className="space-y-2">
                <Label htmlFor="email">Email</Label>
                <Input id="email" type="email" {...register('email')} />
                {errors.email && <span className="text-sm text-red-500">{errors.email.message}</span>}
              </div>
              <div className="space-y-2">
                <Label htmlFor="password">Senha</Label>
                <Input id="password" type="password" {...register('password')} />
                {errors.password && <span className="text-sm text-red-500">{errors.password.message}</span>}
              </div>
              <div className="space-y-2">
                <Label htmlFor="confirm">Confirme a senha</Label>
                <Input id="confirm" type="password" {...register('confirm')} />
                {errors.confirm && <span className="text-sm text-red-500">{errors.confirm.message}</span>}
              </div>

              <Button className="w-full" type="submit" disabled={isSubmitting}>
                Criar conta
              </Button>
            </form>
          </div>
        </div>
      </div>
    </>
  );
}

Tutorial

Estruturando o Formulário

Primeiro, criei um formulário com quatro campos: nome, e-mail, senha e confirmação de senha. Para facilitar o desenvolvimento da interface, utilizei shadcn, tailwind e lucide-react. O uso de classes CSS pode parecer um pouco detalhado, mas elas ajudam a manter um design consistente.

<form className="space-y-4 w-full ">
  <div className="space-y-2">
    <Label htmlFor="name">Nome</Label>
    <Input id="name" type="text" placeholder="Digite o seu nome"/>
  </div>
  <div className="space-y-2">
    <Label htmlFor="email">Email</Label>
    <Input id="email" type="email" placeholder="Digite o seu e-mail"/>
  </div>
  <div className="space-y-2">
    <Label htmlFor="password">Senha</Label>
    <Input id="password" type="password" placeholder="Digite uma senha"/>
  </div>
  <div className="space-y-2">
    <Label htmlFor="confirm">Confirme a senha</Label>
    <Input id="confirm" type="password" placeholder="Digite a senha novamente"/>
  </div>

  <Button className="w-full" type="submit">
    Criar conta
  </Button>
</form>

Criei 4 campos nesse form: nome, e-mail, password e confirm. Preciso validá-los de alguma forma. Como esse exemplo server para explicar o uso de zod, evitei utilizar as propriedades nativas do HTML (required, maxlength etc).

Validação de Dados com Zod

Para garantir que os dados inseridos nos campos estão corretos, criei um schema de validação com o zod. O schema define as restrições para cada campo e personaliza as mensagens de erro:

import { z } from 'zod';

const signUpFormSchema = z
  .object({
    name: z
      .string()
      .min(2, { message: 'Nome deve ter ao menos 2 caracteres' })
      .max(50, { message: 'Nome deve ter no máximo 50 caracteres' }),
    email: z.string().email().max(100, { message: 'E-mail deve ter no máximo 100 caracteres' }),
    password: z.string().max(100, { message: 'Senha deve ter no máximo 100 caracteres' }),
    confirm: z.string(),
  })
  .refine((data) => data.password === data.confirm, {
    message: 'Senhas não conferem!',
    path: ['confirm'],
  });

Esse schema define os tipos e as validações necessárias para cada campo. O método .refine() foi utilizado para garantir que as senhas digitadas nos campos "password" e "confirm" são iguais.

.refine((data) => data.password === data.confirm, {
  message: 'Senhas não conferem!',
  path: ['confirm'],
});

Integração com React Hook Form e Zod Resolver

O React Hook Form é uma biblioteca de formulários que melhora o desempenho ao reduzir re-renderizações desnecessárias e simplificar a manipulação de dados. Usei o useForm() para configurar o formulário, passando o schema de validação por meio do zodResolver:

import { zodResolver } from '@hookform/resolvers/zod';
import { useForm } from 'react-hook-form';

type SignUpForm = z.infer<typeof signUpFormSchema>;

const {
    handleSubmit,
    register,
    reset,
    formState: { isSubmitting, errors },
  } = useForm<SignUpForm>({
    resolver: zodResolver(signUpFormSchema),
  });

As funções e variáveis que utilizei de useForm() são:

handleSubmit: lida com o envio do formulário.
register: vincula campos do formulário ao gerenciamento de dados do React Hook Form.
reset: redefine o formulário.
isSubmitting: indica se o formulário está sendo enviado.
errors: armazena erros de validação de cada campo. ### Função de Envio do Formulário Para simular o envio do formulário, criei a função handleSignup, que adiciona um tempo de espera para visualizar o estado isSubmitting e exibe uma mensagem de sucesso com o toast:

async function handleSignup(data: SignUpForm) {
  console.log(data);
  await new Promise((resolve) => {
    setTimeout(resolve, 2000);
  });
  reset();
  toast.success('Conta criada com sucesso!');
}

Depois adicionei a função ao form:

<form onSubmit={handleSubmit(handleSignup)} className="space-y-4 w-full">

E por fim, utilizei o register para denominar qual campo pertence a qual propriedade, e mostrei os erros (caso eles existam):

<div className="space-y-2">
  <Label htmlFor="name">Nome</Label>
  <Input id="name" type="text" {...register('name')} placeholder="Digite o seu nome" />
  {errors.name && <span className="text-sm text-red-500">{errors.name.message}</span>}
</div>

O resultado ficou assim:

Considerações Finais

Nesse texto, mostrei uma forma simples de integrar React Hook Form e zod para validação de formulários não controlados. A biblioteca também funciona com componentes controlados, então consulte a documentação para explorar mais opções.

EF Core - Explosão Cartesiana

👨‍💻 Lucas Silva — Thu, 03 Oct 2024 18:38:43 +0000

Introdução

Atuei em vários projetos que utilizavam EF Core, e em uma determinada ocasião, encontrei, junto ao meu time, um problema que não fazia muito sentido: uma query simples, com poucos Includes, em tabelas que não possuíam tanto registros (quando comparada a outras tabelas do mesmo banco), estourava timeout. Após análise, o time entendeu que o problema ocorria devido a um fenômeno chamado Explosão cartesiana.

O que é?

A explosão cartesiana ocorre quando, ao realizar queries com joins em propriedades de navegação de entidades no mesmo nível hierárquico em bancos relacionais, o banco de dados retorna um produto vetorial (cross product). Ou seja, cada linha de uma propriedade de navegação é combinada com cada linha da outra propriedade.

Esse comportamento pode gerar um número inesperado de combinações entre os dados, aumentando drasticamente o volume de informações trafegadas entre o banco de dados e a aplicação. Consequentemente, isso pode afetar o desempenho da aplicação, aumentar os custos de infraestrutura e consumo de recursos, além de tornar a depuração e otimização mais complexa.

Como resolver?

Uma das melhores formas de lidar com isso é utilizando queries separadas para carregar os dados envolvidos. O EF Core oferece uma solução simples para isso através do método AsSplitQuery(), que carregará as coleções utilizando múltiplas queries, em vez de uma única query.

Os exemplos abaixo foram feitos com uma coleção de 100000 blogs armazenados em uma instância de SQL Server 2022, rodando através de um contêiner Docker.

Exemplo sem AsSplitQuery

Código:

var withoutSplitQuery = context.Blogs
    .Include(b => b.Posts)
    .Include(b => b.BlogContributors)
        .ThenInclude(bc => bc.Contributor)
    .ToList();

Nesse exemplo, cada Blog possui uma coleção de Posts e uma de BlogContributors. Como ambas estão no mesmo nível, cada post será combinado com cada contribuinte, o que resulta em um número de linhas maior do que o necessário.

Query gerada:

SELECT [b].[BlogId], [b].[Name], [p].[PostId], [p].[BlogId], [p].[Content], [p].[Title], [t].[BlogId], [t].[ContributorId], [t].[ContributorId0], [t].[Name]
      FROM [Blogs] AS [b]
      LEFT JOIN [Posts] AS [p] ON [b].[BlogId] = [p].[BlogId]
      LEFT JOIN (
          SELECT [b0].[BlogId], [b0].[ContributorId], [c].[ContributorId] AS [ContributorId0], [c].[Name]
          FROM [BlogContributors] AS [b0]
          INNER JOIN [Contributors] AS [c] ON [b0].[ContributorId] = [c].[ContributorId]
      ) AS [t] ON [b].[BlogId] = [t].[BlogId]
      ORDER BY [b].[BlogId], [p].[PostId], [t].[BlogId], [t].[ContributorId]

Resultado na busca de 100000 registros:

*************************************************************************
Tempo de execução sem splitquery: 4526ms
Número de blogs retornados: 100000
*************************************************************************

Exemplo com AsSplitQuery

Código:

var withSplitQuery = context.Blogs
    .Include(b => b.Posts)
    .Include(b => b.BlogContributors)
        .ThenInclude(bc => bc.Contributor)
    .AsSplitQuery()
    .ToList();

Queries geradas:

SELECT [b].[BlogId], [b].[Name]
      FROM [Blogs] AS [b]
      ORDER BY [b].[BlogId]

SELECT [p].[PostId], [p].[BlogId], [p].[Content], [p].[Title], [b].[BlogId]
      FROM [Blogs] AS [b]
      INNER JOIN [Posts] AS [p] ON [b].[BlogId] = [p].[BlogId]
      ORDER BY [b].[BlogId]

SELECT [t].[BlogId], [t].[ContributorId], [t].[ContributorId0], [t].[Name], [b].[BlogId]
      FROM [Blogs] AS [b]
      INNER JOIN (
          SELECT [b0].[BlogId], [b0].[ContributorId], [c].[ContributorId] AS [ContributorId0], [c].[Name]
          FROM [BlogContributors] AS [b0]
          INNER JOIN [Contributors] AS [c] ON [b0].[ContributorId] = [c].[ContributorId]
      ) AS [t] ON [b].[BlogId] = [t].[BlogId]
      ORDER BY [b].[BlogId]

Resultado na busca de 100000 registros:

*************************************************************************
Tempo de execução com splitquery: 3664ms
Número de blogs retornados: 100000
*************************************************************************

Por mais que os exemplos acima tenham utilizado um número relativamente pequeno de dados, os resultados de 10 execuções do teste com dados diferentes foram consistentes: as buscas com queries separadas foram mais rápidas que as buscas com queries únicas. Inclusive, o próprio EF lança um erro ao executar uma query que possa causar uma explosão cartesiana:

Compiling a query which loads related collections for more than onecollection navigation, either via 'Include' or through projection, but no 'QuerySplittingBehavior' has been configured. By default, Entity Framework will use 'QuerySplittingBehavior.SingleQuery', which can potentially result in slow query performance.

Importante!
Há inúmeras variáveis que podem impactar na performance de uma query. Esse texto e os testes acima tratam exclusivamente sobre o problema de explosão cartesiana.

Configuração via DbContext

O EF permite a configuração do comportamento como padrão. Para isso, basta configurar o DbContext:

optionsBuilder
    .UseSqlServer("ConnectionString", o =>
    .UseQuerySplittingBehavior(QuerySplittingBehavior.SplitQuery));

Fontes e recursos

TestContainers for integration testing .Net applications

👨‍💻 Lucas Silva — Tue, 10 Sep 2024 13:37:57 +0000

Intro

Unlike unit tests, integration tests allow validating the behavior of an application when all its components are used together. This includes databases, cache services, messaging services, etc.

In theory, everything seems interesting and simple. But these tests can generate and alter a large volume of data, so it is necessary to be careful with the resources used. After all, accidents happen, and you might end up executing a DELETE without WHERE, leading to the total deletion of a table. 😅

To avoid these kinds of problems, it's possible to create these resources using Docker containers through the TestContainers library.

In this tutorial, I'll explain the steps for using these containers in a .NET API.

API

The complete project can be found at this link. It's a task management API (the famous "To-Do list"). It consists basically of three parts:

An entity:

namespace IntegrationTestingDemo.API;

public class Todo
{
    public Todo()
    {
    }

    public Todo(string title, string description)
    {
        Title = title;
        Description = description;
        Id = Guid.NewGuid().ToString().Replace("-", "");
        CreatedAt = DateTime.UtcNow;
        Done = false;
    }

    public string Id { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public bool Done { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime? CompletedAt { get; set; }
}

A service (for simplicity's sake, some operations were not created):

public class TodoService(TodoContext context) : ITodoService
{
    private readonly TodoContext _context = context;

    public async Task<string> Create(string title, string description)
    {
        var todo = new Todo(title, description);
        await _context.AddAsync(todo);
        await _context.SaveChangesAsync();
        return todo.Id;
    }

    public async Task<List<Todo>> GetAll()
    {
        return await _context.Todos.OrderBy(x => x.CreatedAt).ToListAsync();
    }

    public async Task<Todo> GetById(string id)
    {
        return await _context.Todos.FirstOrDefaultAsync(x => x.Id == id);
    }
}

And a controller:

[ApiController]
[Route("[controller]")]
public class TodoController(ITodoService todoService) : ControllerBase
{
    private readonly ITodoService _todoService = todoService;

    [HttpPost]
    public async Task<IActionResult> Create([FromBody] CreateTodoModel model)
    {
        var result = await _todoService.Create(model.Title, model.Description);
        return CreatedAtRoute(nameof(GetById), routeValues: new { Id = result }, result);
    }

    [HttpGet]
    public async Task<IActionResult> GetAll()
    {
        var todos = await _todoService.GetAll();
        return Ok(todos);
    }

    [HttpGet("{id}", Name = "GetById")]
    public async Task<IActionResult> GetById(string id)
    {
        var todo = await _todoService.GetById(id);
        return Ok(todo);
    }
}

Tests

The TestContainer configuration is done when creating the WebApplicationFactory for integration tests. For this tutorial, I decided to use PostgreSQL. Creating it can be done as follows:

private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder().WithUsername("postgres").WithPassword("postgres").Build();

You can change the username and password as desired. There is also the option to change other settings in the builder, such as the db name, host etc.

You can obtain the container's connection string as follows:

_postgres.GetConnectionString()

It may be necessary to remove the dbContext from the application to add a new one with the connection string from the test container. If that's the case, you can do it as follows:

var context = services.FirstOrDefault(descriptor => descriptor.ServiceType == typeof(TodoContext));
if (context != null)
{
    services.Remove(context);
    var options = services.Where(r => (r.ServiceType == typeof(DbContextOptions))
      || (r.ServiceType.IsGenericType && r.ServiceType.GetGenericTypeDefinition() == typeof(DbContextOptions<>))).ToArray();
    foreach (var option in options)
    {
        services.Remove(option);
    }
}

services.AddDbContext<TodoContext>(options =>
{
    options.UseNpgsql(_postgres.GetConnectionString());
});

Finally, it is interesting that your WebApplicationFactory class implements the IAsyncLifetime interface so that the created container is initialized/stopped.

public Task InitializeAsync()
{
    return _postgres.StartAsync();
}

public new Task DisposeAsync()
{
    return _postgres.StopAsync();
}

With the setup done, it is already possible to create integration tests. In the test below, I've used TodoService to create a Todo, then checked if its data was saved as expected:

[Fact]
public async Task Create_ShouldCreateTodoAndReturnItsId()
{
    // Act
    var result = await _todoService.Create(TestTitle, TestDescription);

    // Assert
    var todo = await _dbContext.Todos.FirstOrDefaultAsync(x => x.Id == result);
    Assert.NotNull(todo);
    Assert.False(todo.Done);
    Assert.Equal(TestTitle, todo.Title);
    Assert.Equal(TestDescription, todo.Description);
}

GitHub actions

It is possible to integrate the tests into a pipeline. This post by Milan Jovanović shows how to integrate them into a Github Action:

name: Run Tests 🚀

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  run-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '8.0.x'

      - name: Restore
        run: dotnet restore ./IntegrationTestingDemo.sln

      - name: Build
        run: dotnet build ./IntegrationTestingDemo.sln --no-restore

      - name: Test
        run: dotnet test ./IntegrationTestingDemo.sln --no-build

This is the end of the tutorial. I hope it has been enough to help you implement integration tests with TestContainers in your application.

Until next time!

TestContainers para testes de integração com .Net

👨‍💻 Lucas Silva — Tue, 10 Sep 2024 13:34:51 +0000

Introdução

Diferente de testes de unidade, os testes de integração permitem validar o comportamento de uma aplicação quando todos os componentes dela são utilizados em conjunto. Isso inclui bancos de dados, serviços de cache, serviços de mensageria etc.

Na teoria, tudo parece interessante e simples. Mas esses testes podem gerar e alterar um grande volume de dados, então é necessário tomar cuidado com os recursos utilizados. Até porque acidentes acontecem, e talvez, em um descuido, você pode acabar executando um DELETE sem WHERE, levando à exclusão total de uma tabela. 😅

Para evitar esse tipo de problemas, é possível criar esses recursos a partir de containers Docker por meio da lib TestContainers.

Neste tutorial, explicarei os passos para a utilização desses containers em uma API .Net.

API

O projeto completo pode ser encontrado neste link. Trata-se de uma API de gerenciamento de tarefas (a famosa "To-Do list"). Ela consiste de basicamente 3 partes:

Uma entidade:

namespace IntegrationTestingDemo.API;

public class Todo
{
    public Todo()
    {
    }

    public Todo(string title, string description)
    {
        Title = title;
        Description = description;
        Id = Guid.NewGuid().ToString().Replace("-", "");
        CreatedAt = DateTime.UtcNow;
        Done = false;
    }

    public string Id { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public bool Done { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime? CompletedAt { get; set; }
}

Um service com a lógica da aplicação (visando a simplicidade, algumas operações não foram criadas):

public class TodoService(TodoContext context) : ITodoService
{
    private readonly TodoContext _context = context;

    public async Task<string> Create(string title, string description)
    {
        var todo = new Todo(title, description);
        await _context.AddAsync(todo);
        await _context.SaveChangesAsync();
        return todo.Id;
    }

    public async Task<List<Todo>> GetAll()
    {
        return await _context.Todos.OrderBy(x => x.CreatedAt).ToListAsync();
    }

    public async Task<Todo> GetById(string id)
    {
        return await _context.Todos.FirstOrDefaultAsync(x => x.Id == id);
    }
}

E um controller:

[ApiController]
[Route("[controller]")]
public class TodoController(ITodoService todoService) : ControllerBase
{
    private readonly ITodoService _todoService = todoService;

    [HttpPost]
    public async Task<IActionResult> Create([FromBody] CreateTodoModel model)
    {
        var result = await _todoService.Create(model.Title, model.Description);
        return CreatedAtRoute(nameof(GetById), routeValues: new { Id = result }, result);
    }

    [HttpGet]
    public async Task<IActionResult> GetAll()
    {
        var todos = await _todoService.GetAll();
        return Ok(todos);
    }

    [HttpGet("{id}", Name = "GetById")]
    public async Task<IActionResult> GetById(string id)
    {
        var todo = await _todoService.GetById(id);
        return Ok(todo);
    }
}

Testes

A configuração de TestContainer é feita na criação da WebApplicationFactory para os testes de integração. Neste tutorial, decidi utilizar PostgreSQL. A criação de um container desse banco de dados pode ser feita da seguinte forma:

private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder().WithUsername("postgres").WithPassword("postgres").Build();

É possível alterar o usuário e a senha da forma que desejar. Há, inclusive, a opção de alterar outras configurações no builder, como o nome do db, o host etc.

Com o container criado, é possível obter a connection string dele da seguinte forma:

_postgres.GetConnectionString()

Pode ser necessário remover o dbContext da aplicação para adicionar um novo com a connection string do container de teste. Nesse caso, é possível fazê-lo da seguinte forma:

var context = services.FirstOrDefault(descriptor => descriptor.ServiceType == typeof(TodoContext));
if (context != null)
{
    services.Remove(context);
    var options = services.Where(r => (r.ServiceType == typeof(DbContextOptions))
      || (r.ServiceType.IsGenericType && r.ServiceType.GetGenericTypeDefinition() == typeof(DbContextOptions<>))).ToArray();
    foreach (var option in options)
    {
        services.Remove(option);
    }
}

services.AddDbContext<TodoContext>(options =>
{
    options.UseNpgsql(_postgres.GetConnectionString());
});

Por fim, é interessante que sua classe de WebApplicationFactory implemente a interface IAsyncLifetime para que o container criado seja inicializado / parado.

public Task InitializeAsync()
{
    return _postgres.StartAsync();
}

public new Task DisposeAsync()
{
    return _postgres.StopAsync();
}

Com a configuração feita, já é possível criar testes de integração. No teste abaixo, utilizei o TodoService para criar uma tarefa, e então verifiquei se os dados no banco de dados estavam de acordo com o que deveriam:

[Fact]
public async Task Create_ShouldCreateTodoAndReturnItsId()
{
    // Act
    var result = await _todoService.Create(TestTitle, TestDescription);

    // Assert
    var todo = await _dbContext.Todos.FirstOrDefaultAsync(x => x.Id == result);
    Assert.NotNull(todo);
    Assert.False(todo.Done);
    Assert.Equal(TestTitle, todo.Title);
    Assert.Equal(TestDescription, todo.Description);
}

(Acesse o repositório para verificar os demais testes.)

O exemplo acima testa uma classe simples. Entretanto, poderia testar uma classe mais complexa, como um Handler, que manipula os dados através de diversos objetos. Além disso, o service foi criado para não testar as chamadas diretas ao controller.

GitHub actions

É possível integrar os testes à pipeline. Essa postagem do Milan Jovanović mostra como integrá-los a uma Github Action:

name: Run Tests 🚀

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  run-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '8.0.x'

      - name: Restore
        run: dotnet restore ./IntegrationTestingDemo.sln

      - name: Build
        run: dotnet build ./IntegrationTestingDemo.sln --no-restore

      - name: Test
        run: dotnet test ./IntegrationTestingDemo.sln --no-build

TestContainers for Integration Testing with .NET

👨‍💻 Lucas Silva — Tue, 06 Feb 2024 20:11:23 +0000

Intro

Unlike unit tests, integration tests allow validating the behavior of an application when all its components are used together. This includes databases, cache services, messaging services, etc.

To avoid these kinds of problems, it's possible to create these resources using Docker containers through the TestContainers library.

In this tutorial, I'll explain the steps for using these containers in a .NET API.

API

The complete project can be found at this link. It's a task management API (the famous "To-Do list"). It consists basically of three parts:

An entity:

namespace IntegrationTestingDemo.API;

public class Todo
{
    public Todo()
    {
    }

    public Todo(string title, string description)
    {
        Title = title;
        Description = description;
        Id = Guid.NewGuid().ToString().Replace("-", "");
        CreatedAt = DateTime.UtcNow;
        Done = false;
    }

    public string Id { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public bool Done { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime? CompletedAt { get; set; }
}

A service (for simplicity's sake, some operations were not created):

public class TodoService(TodoContext context) : ITodoService
{
    private readonly TodoContext _context = context;

    public async Task<string> Create(string title, string description)
    {
        var todo = new Todo(title, description);
        await _context.AddAsync(todo);
        await _context.SaveChangesAsync();
        return todo.Id;
    }

    public async Task<List<Todo>> GetAll()
    {
        return await _context.Todos.OrderBy(x => x.CreatedAt).ToListAsync();
    }

    public async Task<Todo> GetById(string id)
    {
        return await _context.Todos.FirstOrDefaultAsync(x => x.Id == id);
    }
}

And a controller:

[ApiController]
[Route("[controller]")]
public class TodoController(ITodoService todoService) : ControllerBase
{
    private readonly ITodoService _todoService = todoService;

    [HttpPost]
    public async Task<IActionResult> Create([FromBody] CreateTodoModel model)
    {
        var result = await _todoService.Create(model.Title, model.Description);
        return CreatedAtRoute(nameof(GetById), routeValues: new { Id = result }, result);
    }

    [HttpGet]
    public async Task<IActionResult> GetAll()
    {
        var todos = await _todoService.GetAll();
        return Ok(todos);
    }

    [HttpGet("{id}", Name = "GetById")]
    public async Task<IActionResult> GetById(string id)
    {
        var todo = await _todoService.GetById(id);
        return Ok(todo);
    }
}

Tests

The TestContainer configuration is done when creating the WebApplicationFactory for integration tests. For this tutorial, I decided to use PostgreSQL. Creating it can be done as follows:

private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder().WithUsername("postgres").WithPassword("postgres").Build();

You can change the username and password as desired. There is also the option to change other settings in the builder, such as the db name, host etc.

You can obtain the container's connection string as follows:

_postgres.GetConnectionString()

It may be necessary to remove the dbContext from the application to add a new one with the connection string from the test container. If that's the case, you can do it as follows:

var context = services.FirstOrDefault(descriptor => descriptor.ServiceType == typeof(TodoContext));
if (context != null)
{
    services.Remove(context);
    var options = services.Where(r => (r.ServiceType == typeof(DbContextOptions))
      || (r.ServiceType.IsGenericType && r.ServiceType.GetGenericTypeDefinition() == typeof(DbContextOptions<>))).ToArray();
    foreach (var option in options)
    {
        services.Remove(option);
    }
}

services.AddDbContext<TodoContext>(options =>
{
    options.UseNpgsql(_postgres.GetConnectionString());
});

Finally, it is interesting that your WebApplicationFactory class implements the IAsyncLifetime interface so that the created container is initialized/stopped.

public Task InitializeAsync()
{
    return _postgres.StartAsync();
}

public new Task DisposeAsync()
{
    return _postgres.StopAsync();
}

With the setup done, it is already possible to create integration tests. In the test below, I've used TodoService to create a Todo, then checked if its data was saved as expected:

[Fact]
public async Task Create_ShouldCreateTodoAndReturnItsId()
{
    // Act
    var result = await _todoService.Create(TestTitle, TestDescription);

    // Assert
    var todo = await _dbContext.Todos.FirstOrDefaultAsync(x => x.Id == result);
    Assert.NotNull(todo);
    Assert.False(todo.Done);
    Assert.Equal(TestTitle, todo.Title);
    Assert.Equal(TestDescription, todo.Description);
}

GitHub actions

It is possible to integrate the tests into a pipeline. This post by Milan Jovanović shows how to integrate them into a Github Action:

name: Run Tests 🚀

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  run-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '8.0.x'

      - name: Restore
        run: dotnet restore ./IntegrationTestingDemo.sln

      - name: Build
        run: dotnet build ./IntegrationTestingDemo.sln --no-restore

      - name: Test
        run: dotnet test ./IntegrationTestingDemo.sln --no-build

This is the end of the tutorial. I hope it has been enough to help you implement integration tests with TestContainers in your application.

Until next time!

TestContainers para testes de integração com .Net

👨‍💻 Lucas Silva — Tue, 06 Feb 2024 19:58:04 +0000

Introdução

Para evitar esse tipo de problemas, é possível criar esses recursos a partir de containers Docker por meio da lib TestContainers.

Neste tutorial, explicarei os passos para a utilização desses containers em uma API .Net.

API

O projeto completo pode ser encontrado neste link. Trata-se de uma API de gerenciamento de tarefas (a famosa "To-Do list"). Ela consiste de basicamente 3 partes:

Uma entidade:

namespace IntegrationTestingDemo.API;

public class Todo
{
    public Todo()
    {
    }

    public Todo(string title, string description)
    {
        Title = title;
        Description = description;
        Id = Guid.NewGuid().ToString().Replace("-", "");
        CreatedAt = DateTime.UtcNow;
        Done = false;
    }

    public string Id { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public bool Done { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime? CompletedAt { get; set; }
}

Um service com a lógica da aplicação (visando a simplicidade, algumas operações não foram criadas):

public class TodoService(TodoContext context) : ITodoService
{
    private readonly TodoContext _context = context;

    public async Task<string> Create(string title, string description)
    {
        var todo = new Todo(title, description);
        await _context.AddAsync(todo);
        await _context.SaveChangesAsync();
        return todo.Id;
    }

    public async Task<List<Todo>> GetAll()
    {
        return await _context.Todos.OrderBy(x => x.CreatedAt).ToListAsync();
    }

    public async Task<Todo> GetById(string id)
    {
        return await _context.Todos.FirstOrDefaultAsync(x => x.Id == id);
    }
}

E um controller:

[ApiController]
[Route("[controller]")]
public class TodoController(ITodoService todoService) : ControllerBase
{
    private readonly ITodoService _todoService = todoService;

    [HttpPost]
    public async Task<IActionResult> Create([FromBody] CreateTodoModel model)
    {
        var result = await _todoService.Create(model.Title, model.Description);
        return CreatedAtRoute(nameof(GetById), routeValues: new { Id = result }, result);
    }

    [HttpGet]
    public async Task<IActionResult> GetAll()
    {
        var todos = await _todoService.GetAll();
        return Ok(todos);
    }

    [HttpGet("{id}", Name = "GetById")]
    public async Task<IActionResult> GetById(string id)
    {
        var todo = await _todoService.GetById(id);
        return Ok(todo);
    }
}

Testes

private readonly PostgreSqlContainer _postgres = new PostgreSqlBuilder().WithUsername("postgres").WithPassword("postgres").Build();

É possível alterar o usuário e a senha da forma que desejar. Há, inclusive, a opção de alterar outras configurações no builder, como o nome do db, o host etc.

Com o container criado, é possível obter a connection string dele da seguinte forma:

_postgres.GetConnectionString()

Pode ser necessário remover o dbContext da aplicação para adicionar um novo com a connection string do container de teste. Nesse caso, é possível fazê-lo da seguinte forma:

var context = services.FirstOrDefault(descriptor => descriptor.ServiceType == typeof(TodoContext));
if (context != null)
{
    services.Remove(context);
    var options = services.Where(r => (r.ServiceType == typeof(DbContextOptions))
      || (r.ServiceType.IsGenericType && r.ServiceType.GetGenericTypeDefinition() == typeof(DbContextOptions<>))).ToArray();
    foreach (var option in options)
    {
        services.Remove(option);
    }
}

services.AddDbContext<TodoContext>(options =>
{
    options.UseNpgsql(_postgres.GetConnectionString());
});

Por fim, é interessante que sua classe de WebApplicationFactory implemente a interface IAsyncLifetime para que o container criado seja inicializado / parado.

public Task InitializeAsync()
{
    return _postgres.StartAsync();
}

public new Task DisposeAsync()
{
    return _postgres.StopAsync();
}

[Fact]
public async Task Create_ShouldCreateTodoAndReturnItsId()
{
    // Act
    var result = await _todoService.Create(TestTitle, TestDescription);

    // Assert
    var todo = await _dbContext.Todos.FirstOrDefaultAsync(x => x.Id == result);
    Assert.NotNull(todo);
    Assert.False(todo.Done);
    Assert.Equal(TestTitle, todo.Title);
    Assert.Equal(TestDescription, todo.Description);
}

(Acesse o repositório para verificar os demais testes.)

GitHub actions

É possível integrar os testes à pipeline. Essa postagem do Milan Jovanović mostra como integrá-los a uma Github Action:

name: Run Tests 🚀

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  run-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '8.0.x'

      - name: Restore
        run: dotnet restore ./IntegrationTestingDemo.sln

      - name: Build
        run: dotnet build ./IntegrationTestingDemo.sln --no-restore

      - name: Test
        run: dotnet test ./IntegrationTestingDemo.sln --no-build

Este é o fim do tutorial. Espero que esse texto tenha sido o suficiente para te ajudar a implementar testes de integração com TestContainers na sua aplicação.

Até a próxima!

An easy and simple way to implement soft delete in .Net using EF Core

👨‍💻 Lucas Silva — Fri, 19 Jan 2024 14:50:25 +0000

When developing APIs, it's common to have to modify the behavior of DELETE so that instead of deleting a record, it simply changes a boolean property and considers that resource not to exist if the value of the property is false. This technique is known as "Soft Delete."

There are many ways to implement this behavior. The approach presented in this text can be summarized in the following steps:
1- Add a boolean property to the desired class.
2- Override the SaveChangesAsync method of the class that extends DbContext.
3- Add a filter to the entity configuration so that "inactive" entities are not returned in queries.

Add boolean property

The first step is self-explanatory. Create an entity and add the boolean property to it. If multiple entities need this behavior, consider creating a base class or interface that contains it.

Override the SaveChangesAsync method

If you use EF Core, you likely extended the DbContext class to create your context. The base class has a method called SaveChangesAsync, which saves the changes made to the database.

The following code aims to detect the state of the entities tracked by the ChangeTracker. If any has been deleted, it will change its state to Unchanged (instead of Deleted) and then change the boolean property added in the previous step.

public override Task<int> SaveChangesAsync(bool acceptAllChangesOnSuccess, CancellationToken cancellationToken = default)
{
    foreach (var entry in ChangeTracker.Entries<T>()) // Where "T" is the entity type
    {
        switch (entry.State)
        {
            case EntityState.Deleted:
                entry.State = EntityState.Unchanged;
                entry.Entity.BooleanProperty = false; // Prefer using a method for this.
                break;
        }
    }
    return base.SaveChangesAsync(acceptAllChangesOnSuccess, cancellationToken);
}

Add filter

With the modification made, it's now possible to update all queries so they ignore entities where the value of the boolean property is false. However, depending on the size of your application, this may be a quite tedious task.

To avoid the described situation, EF provides a way to do this automatically through entity configuration. Example:

public class YourEntityConfiguration : IEntityTypeConfiguration<YourEntity>
{
    public void Configure(EntityTypeBuilder<YourEntity> builder)
    {
        builder.HasQueryFilter(x => x.Active);
    }
}

The above code ensures that only entities with the Active property set to true are returned in queries.

We've reached the end of the tutorial. I hope this text has been enough to implement basic Soft Delete behavior in your application.

Uma forma simples de realizar soft delete em .Net utilizando Entity Framework Core

👨‍💻 Lucas Silva — Fri, 19 Jan 2024 14:26:31 +0000

Ao desenvolver APIs, é comum ter de alterar o comportamento de DELETE para que, em vez de excluir o registro, simplesmente alterar uma propriedade booleana e considerar que aquele recurso não existe caso o valor da propriedade seja false. Essa técnica é conhecida como "Soft Delete".

Há várias formas de implementar esse comportamento. A forma apresentada neste texto pode ser resumida aos seguintes passos:
1- Adicionar uma propriedade booleana à classe desejada;
2- Sobrescrever o método SaveChangesAsync da classe que estende DbContext;
3- Adicionar um filtro na configuração da entidade para que as entidades "inativas" não sejam retornadas em queries.

Adicionar propriedade booleana

O primeiro passo é autoexplicativo. Crie uma entidade e adicione a propriedade booleana a ela. Caso várias entidades precisem desse comportamento, considere criar uma classe base ou interface que a contenha.

Sobrescrever o método SaveChangesAsync

Se você utiliza o EF, é provável que tenha estendido a classe DbContext para criar um contexto próprio. A classe base possui um método chamado SaveChangesAsync, o qual salva as alterações feitas no banco de dados.

A alteração que será realizada no método visa detectar o estado das entidades rastreadas pelo ChangeTracker. Caso alguma tenha sido deletada, será necessário mudar o estado dela para Unchanged (em vez de Deleted), e então alterar a propriedade booleana adicionada no passo anterior.

public override Task<int> SaveChangesAsync(bool acceptAllChangesOnSuccess, CancellationToken cancellationToken = default)
{
    foreach (var entry in ChangeTracker.Entries<T>()) // Onde "T" é o tipo da entidade
    {
        switch (entry.State)
        {
            case EntityState.Deleted:
                entry.State = EntityState.Unchanged;
                entry.Entity.PropriedadeBooleana = false; // Prefira utilizar um método para isso.
                break;
        }
    }
    return base.SaveChangesAsync(acceptAllChangesOnSuccess, cancellationToken);
}

Adicionar filtro

Com a alteração feita, já é possível alterar todas as queries para que elas deconsiderem entidades às quais o valor da propriedade booleana seja false. Entretanto, dependendo do tamanho da sua aplicação, essa tarefa poderá ser bastante trabalhosa.

Para evitar a situação descrita acima, o EF fornece uma forma de realizar isso de forma automática através da configuração da entidade. Exemplo:

public class SuaEntidadeConfiguration: IEntityTypeConfiguration<SuaEntidade>
{
    public void Configure(EntityTypeBuilder<SuaEntidade> builder)
    {
        builder.HasQueryFilter(x => x.Active);
    }
}

O código acima faz com que somente as entidades que possuam a propriedade Active como true sejam retornadas em caso de queries.

Chegamos ao fim do tutorial. Espero que este texto tenha sido o suficiente para a implementação de um comportamento básico de Soft delete na sua aplicação.

Github action para jogos da Unity

👨‍💻 Lucas Silva — Sun, 16 Jul 2023 19:31:32 +0000

Após brincar com desenvolvimento de jogos por alguns anos, decidi levar a sério a carreira de game dev e abri um estúdio de jogos chamado Blue Flower Game Lab.
Estou desenvolvendo meu primeiro projeto sozinho, então tenho tentado automatizar meus processos ao máximo. Foi assim que descobri a Game.ci, uma maneira de automatizar builds de projetos da Unity através do GitHub Actions.

Configuração

Ativação e secrets

Crie um arquivo chamado .github/workflows/activation.yml e cole o seguinte conteúdo nele:

name: Acquire activation file
on:
  workflow_dispatch: {}
jobs:
  activation:
    name: Request manual activation file 🔑
    runs-on: ubuntu-latest
    steps:
      # Request manual activation file
      - name: Request manual activation file
        id: getManualLicenseFile
        uses: game-ci/unity-request-activation-file@v2
      # Upload artifact (Unity_v20XX.X.XXXX.alf)
      - name: Expose as artifact
        uses: actions/upload-artifact@v2
        with:
          name: ${{ steps.getManualLicenseFile.outputs.filePath }}
          path: ${{ steps.getManualLicenseFile.outputs.filePath }}

Execute essa ação. O resultado dela será um arquivo de ativação manual. Depois disso, pegue o arquivo e faça o upload dele em license.unity3d.com para obter um arquivo de licença.
Com o arquivo de licença em mãos, será necessário criar os seguintes segredos no repositório do seu jogo:

UNITY_LICENSE: conteúdo obtido no arquivo de licença;
UNITY_EMAIL: e-mail de login na Unity;
UNITY_PASSWORD: senha para login na Unity.

Nota: a senha e o e-mail não são solicitados nem armazenados pela game.ci. São necessárias apenas para reativação da licença durante o processo de build.

Build

Após obter a licença e configurar os secrets, crie um novo arquivo de pipeline com o seguinte conteúdo:

name: Build

on:
  push:
    branches:
      - main

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        targetPlatform:
          # - StandaloneOSX # Build a macOS standalone (Intel 64-bit).
          # - StandaloneWindows # Build a Windows standalone.
          # - StandaloneWindows64 # Build a Windows 64-bit standalone.
          # - StandaloneLinux64 # Build a Linux 64-bit standalone.
          # - iOS # Build an iOS player.
          # - Android # Build an Android .apk standalone app.
          # - WebGL # WebGL.
    steps:
      # Checkout
      - name: Checkout repository
        uses: actions/checkout@v2
        with:
          lfs: true

      # Cache
      - uses: actions/cache@v2
        with:
          path: Library
          key: Library-${{ hashFiles('Assets/**', 'Packages/**', 'ProjectSettings/**') }}
          restore-keys: |
            Library-

      # Build
      - name: Build project
        uses: game-ci/unity-builder@v2
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
        with:
          targetPlatform: ${{ matrix.targetPlatform }}

      # Output
      - uses: actions/upload-artifact@v2
        with:
          name: Build
          path: build

      # Discord notification
      - name: Discord Notifier
        uses: madebyluque/action-discord-notifier@v1.1.1
        with:
          webhook: Webhook do canal do discord
          message-title: Título da mensagem do discord
          message-description: Descrição da mensagem

Com o arquivo criado, você precisará apenas selecionar as plataformas alvo. Para isso, remova o símbolo "#" das plataformas desejadas na seção targetPlatform.

O último passo da pipeline envia uma notificação a um canal do Discord. Como a execução dela pode passar de 10 minutos, optei por ser avisado da conclusão dela em vez de ficar esperando. Para isso, fiz o fork de uma ação no github e modifiquei algumas informações para poder personalizar o título e a descrição da mensagem. Esse passo é opcional, então fique à vontade para removê-lo.

Recursos e dicas para o desenvolvimento do seu primeiro game

👨‍💻 Lucas Silva — Mon, 20 Feb 2023 19:04:14 +0000

Fotos de Foto de Sigmund e Jacek Dylag.

Bem, é muito provável que você, assim como eu, sempre sonhou em desenvolver seus próprios jogos. Assim que mudei de carreira e comecei a programar, decidi que tiraria esse sonho do papel e o tornaria realidade. Ainda não consegui terminar meu game, mas as coisas estão caminhando bem. Trarei aqui algumas dicas para que você possa fazer o mesmo.

Antes de mais nada: é um processo longo e trabalhoso

Se você está começando do zero, saiba que criar um jogo é um processo trabalhoso. Sério. Você pode agilizá-lo com algumas das dicas deste texto, mas no geral, você vai passar alguns meses/anos trabalhando na arte, no código, no design de níveis, no som...
Inclusive, saiba que todo projeto de vida tem um custo muito alto: seu tempo. Entretanto, mesmo que você não se torne o novo Eric Barone, o conhecimento adquirido ao criar um projeto seu, é extremamente valioso.

Game Engine

Se você estiver pensando em realizar o seu primeiro projeto, não comece por criar uma game engine. Há milhares de engines gratuitas por aí, então não reinvente a roda.

Uma game engine é um software voltado ao desenvolvimento de jogos. Será nela que você criará seus níveis, scripts, mecânicas do jogo etc. A escolha de uma boa game engine basicamente ditará se o seu projeto será terminado ou não.
Há alguns pontos a serem considerados, como facilidade para gerar as versões finais (builds) do projeto, facilidade para criação de scripts, facilidade para trabalhar os objetos etc.
Pensando nisso, a minha escolha pessoal é a Unity. É possível criar jogos 2D, 3D, jogos para realidade virtual e outros. Além disso, ela simplifica o processo de "buildar" seu jogo para celulares, pcs, consoles etc.
A linguagem de programação da Unity é o C#, uma linguagem vastamente consolidada no mercado. A documentação dela é completa e há tutoriais incríveis sobre ela na internet. Entretanto, há um ponto de atenção: por mais que a documentação da linguagem seja incrível, a documentação da unity não é muito boa, e muitas vezes você precisará recorrer a canais do Youtube (veja nas referências).
Eu tentei outras das engines que recomendam na internet mas não consegui avançar muito com elas. Caso queira saber mais, os links são:

GameMaker: você não precisa saber programar para conseguir fazer um jogo usando ela;
Godot;

Arte visual

Essa tem sido a parte mais difícil nos meus projetos. Eu até consigo desenhar, mas criar artes que encham as pessoas de sensações não é uma tarefa fácil. E não se engane: muitas pessoas abandonarão seu game se a arte não interessá-las.
Isso não significa que seu game precisa ser extremamente realista. Ele só precisa ser agradável aos olhos, e isso é bastante subjetivo (logo, não tente agradar todo mundo).

Você pode usar uma ou várias ferramentas para criar sua arte. Aqui estão algumas das minhas favoritas:

Krita: desenho e pintura digital;
Piskel: pixel art;
Blender: arte e modelagem 3D;
Tiled: criação de tilemaps e editor de níveis;
PureRef: referência de imagens.

Entretanto, assim como com as Game Engines, você não precisa criar tudo do zero. Há sites que vendem assets ou até mesmo disponibilizam eles gratuitamente. O canal Game Dev Unlocked fala sobre como assets gratuitos foram importantes na criação do game The First Tree. Você pode encontrar esses assets no itch, na Unity Asset Store ou em outros sites.

Som

O som pode fazer seu jogo ser incrível ou extremamente chato
-- inclusive, não consigo jogar Splatoon devido às músicas apresentadas nos trailers.
Gosto bastante do LMMS para criação de músicas. Entretanto, no meu projeto atual, decidi partir para algo mais manual, então comprei uma interface de áudio (Teyun Q-22) e estou utilizando o Audacity e o Guitar Rig 5 para gravar músicas diretamente com a guitarra e o violão.
Você precisará entender alguns conceitos antes de compor para seu game. Não basta apenas pegar um instrumento e sair tocando notas de forma desgovernada. A palestra do Leo Borges no GDTK 2021 me ajudou a entender as necessidades sonoras do meu game, e recomendo que você a assista.

Há outros tipos de áudio em jogos. Sons de passos, de portas abrindo (quem lembra das portas de Resident Evil do PS1 se abrindo?). Costumo usar o site OpenGameArt para buscar esse tipo de áudio.

Fim?

Na verdade, espero que esse seja um início. Pelo menos para o seu projeto. Senta na cadeira, escolhe a engine, baixa uns assets e começa o teu game. Sério. Não espere mais tempo para isso.
Se, assim como eu, você tiver dúvidas se vale ou não a pena criar um jogo, minha resposta é: sempre vale.

Se precisar de uma ajuda, uma mentoria, ou apenas quiser falar sobre game dev, siga-me no twitter ou envie um e-mail para lucas@blueflowergamelab.com.

Enfim, espero que este texto tenha te ajudado. Vou deixar uns links na sessão de recursos para você conseguir seguir adiante com seu projeto.

Até a próxima!

Recursos

Automatizando a criação de requisições no JMeter utilizando Postman

👨‍💻 Lucas Silva — Tue, 19 Jul 2022 01:51:29 +0000

Faz um tempo que não escrevo por aqui, mas hoje, enquanto estudava para resolver um problema do trampo, me deparei com uma técnica que facilitou muito a forma de criar requisições no JMeter, então decidi compartilhá-la.

Antes de mais nada, quero agradecer aos meus amigos Jurno e João, que me guiaram na busca pela solução.

Sem mais delongas, bora pro problema.

O problema

Imagine que em um determinado momento, você e seu time precisarão realizar um teste de carga na aplicação que vocês desenvolvem. Entretanto, vocês possuem pouco ou nenhum conhecimento com a ferramenta JMeter, uma das mais utilizadas para esse tipo de tarefa.
Uma das possíveis soluções é gastar um bom tempo lendo a documentação para aprender a criar as requisições uma a uma. Inclusive, essa teria sido a minha decisão, não fosse pelos conselhos dos amigos citados acima.

A solução

É possível adicionar um elemento ao plano de teste do JMeter chamado HTTP(S) Test Script Recorder. Ele é responsável por gravar requisições http e transformá-las em uma HTTP Request (sampler).

Com esse elemento adicionado, basta ajustar as configurações de proxy do Postman (ou qualquer outro sistema que você utiliza) para o endereço do Test Script Recorder (localhost:8888 por default), rodar o elemento e então realizar uma requisição no sistema a ser testado.

Fiz uma requisição de exemplo na PokéAPI, e eis a requisição montada automaticamente no JMeter:

É possível que seja necessário realizar algumas alterações na requisição gerada, mas creio que o procedimento descrito acima seja um excelente ponto de entrada para requisições mais elaboradas.

Bem, caso haja alguma dúvida sobre o texto ou alguma sugestão de melhoria, peço que envie um comentário 😎.
Até a próxima!