DEV Community: Matheus Torres

Como apliquei POO em um projeto pessoal pequeno: um estudo de caso de um Console App C#

Matheus Torres — Mon, 09 Jun 2025 03:23:09 +0000

Como apliquei POO em um projeto pessoal pequeno: um estudo de caso de um Console App C\

✨ Introdução

Ao aprender C# e me aprofundar no ecossistema .NET, decidi iniciar um projeto pessoal simples: um simulador de blog em formato Console App. A ideia era desenvolver uma aplicação que permitisse adicionar, listar, atualizar e remover posts, já com a visão futura de transformá-la em uma aplicação web fullstack usando ASP.NET Core no backend e Angular no frontend.

O que mais me surpreendeu é que, mesmo em um projeto pequeno, acabei aplicando diversos conceitos fundamentais de Programação Orientada a Objetos (POO). Neste artigo, compartilho esse estudo de caso, explicando como cada conceito foi usado na prática.

🪡 Contexto do projeto

O projeto consiste em:

Um modelo de dados chamado Post
Um serviço chamado PostService que realiza operações CRUD
Um menu de interação no Program.cs que atua como interface de texto

🔐 Encapsulamento

Encapsulamento é o conceito de proteger os dados internos de um objeto, expondo apenas o necessário através de métodos públicos.

Onde usei:

Na classe Post, onde os dados são representados como propriedades com get; set;
No PostService, a lista interna de posts é privada e só pode ser manipulada por métodos como AddPost(), RemovePost() e UpdatePost()

List<Post> posts = new List<Post>(); // encapsulada dentro do serviço

🔹 Abstração

Abstração é sobre esconder detalhes complexos e mostrar apenas o essencial.

Onde usei:

Program.cs não acessa diretamente a lista de posts, ele apenas chama os métodos de PostService
A lógica de como os posts são armazenados, buscados ou editados fica escondida dentro do serviço

Isso separa bem a responsabilidade entre interface com o usuário e lógica de negócio.

🏢 Responsabilidade Única (SRP)

Cada classe no projeto tem uma única responsabilidade:

Classe	Responsabilidade
`Post`	Representar os dados de um post
`PostService`	Gerenciar a lógica de negócio e CRUD
`Program.cs`	Gerenciar o menu e entrada do usuário

Essa separação facilita testes, manutenção e futura expansão para API.

👨‍💼 Instanciação de objetos

Criei objetos com new a partir das classes, como por exemplo:

Criar um post:

Post newPost = new Post { Title = ..., Content = ..., Author = ... };

Usar o serviço:

PostService postService = new PostService();

🌐 Próximos passos

Migrar este projeto para ser uma API ASP.NET

* Criar interface Angular para consumir a API

🚀 Conclusão

Mesmo em um projeto simples e pequeno, consegui aplicar de forma natural os principais conceitos de programação orientada a objetos. Isso me mostrou que entender bem POO é uma base essencial para crescer como desenvolvedor.

Esse projeto ainda vai evoluir para algo maior (uma aplicação fullstack), mas já me deu uma base sólida e realista sobre boas práticas de organização de código.

Se você estiver aprendendo C# ou iniciando na carreira, recomendo fortemente começar com algo pequeno, mas bem estruturado. A experiência de aplicar POO na prática faz toda a diferença!

Repositório: PortfolioBlog no GitHub

Criando um Servidor de Streaming 24/7: Parte 3 - Codificação e Entrega com FFPlayout e Nginx

Matheus Torres — Sat, 31 May 2025 17:16:22 +0000

Após superar os desafios com o MediaMTX, veio uma fase mais tranquila — mas nem por isso menos interessante. Era hora de colocar os vídeos no ar e entregá-los ao público, com qualidade e estabilidade.

🎞️ Codificação com FFPlayout + FFmpeg

O FFPlayout foi a ferramenta escolhida para gerenciar as playlists e codificar os vídeos. Apesar de eu já ter ouvido falar do FFmpeg, nunca havia mexido diretamente com ele em um fluxo de produção.

O desafio aqui foi entender e configurar corretamente os parâmetros do FFmpeg:

ffmpeg -re -i input.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency \
-c:a aac -f flv rtmp://localhost:1935/live/canal1

Com a ajuda da documentação, fui aprendendo o significado de cada flag:

-re: simula reprodução em tempo real

-preset veryfast: equilibra qualidade e performance

-tune zerolatency: otimiza para streaming ao vivo

Testar os resultados e ver o MediaMTX recebendo o fluxo foi um daqueles momentos de empolgação genuína:

[RTMP] [conn 127.0.0.1:XXXXX] is publishing to path 'live/canal1'

🌐 Entrega ao público com Nginx

Com o servidor gerando o HLS corretamente, era hora de servir os arquivos para fora. A missão agora era configurar o Nginx como proxy reverso, apontando para o domínio tv.lftv.com.br.

Essa parte teve dois grandes focos:

Fazer o Nginx redirecionar os acessos para o MediaMTX na porta 8888

Garantir que tudo estivesse protegido com HTTPS

Configuração básica do proxy:

server {
listen 80;
server_name xxx;

location /hls/ {
    proxy_pass http://localhost:8888/hls/;
    add_header Access-Control-Allow-Origin "$http_origin" always;
    add_header Access-Control-Allow-Credentials true;
    add_header Access-Control-Allow-Methods "GET, OPTIONS";
    proxy_buffering off;
}

}

Ativando HTTPS com Certbot e Let's Encrypt:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d dominio

Em poucos minutos, o domínio estava pronto para transmitir com segurança.

🔐 Os desafios do CORS

Apesar do setup HTTPS ter sido facilitado por automação, configurar o CORS (Cross-Origin Resource Sharing) foi mais delicado. Players em smart TVs (como WebOS ou Tizen) exigem permissões específicas, e o uso de credentials: true exige Access-Control-Allow-Origin dinâmico:

add_header 'Access-Control-Allow-Origin' "$http_origin" always;
add_header 'Access-Control-Allow-Credentials' 'true';

Demorei até encontrar essa combinação estável, mas quando consegui, todos os players passaram a tocar o conteúdo sem bloqueios.

Essa etapa consolidou o pipeline do streaming, do vídeo até o navegador. Cada peça foi conectada com cuidado, e o resultado era visível: o canal estava no ar 24/7.

Criando um Servidor de Streaming 24/7: Parte 2 - Os desafios com o MediaMTX

Matheus Torres — Sat, 31 May 2025 17:15:16 +0000

A etapa seguinte foi uma das mais frustrantes de toda a jornada: configurar o MediaMTX corretamente. Mesmo sendo uma ferramenta poderosa, a documentação limitada e a extrema sensibilidade a erros de configuração tornaram essa fase um verdadeiro teste de paciência.

🧱 O início com o MediaMTX

O MediaMTX (anteriormente rtsp-simple-server) era perfeito para o que eu precisava: receber RTMP, gerar HLS, e ainda oferecer suporte a SRT. Baixei a versão estável, instalei e... nada funcionava direito.

A única referência oficial era um arquivo gigantesco de configuração em YAML no repositório do GitHub. Sem muitos comentários ou explicações, era um território difícil de navegar.

⚠️ O terror do YAML

Cometi inúmeros erros por causa de:

Espaços mal posicionados (YAML é extremamente sensível)

Estruturas mal interpretadas (ex: tentar usar hls: como objeto ao invés de enable: yes)

Tipos errados (booleanos confundidos com strings)

Resultado: o serviço falhava silenciosamente ou emitia erros vagos nos logs.

Com o tempo, aprendi a consultar constantemente os logs com:

tail -f /var/log/mediamtx/mediamtx.log

E corrigir a configuração. Um exemplo funcional mínimo:

rtmp:
enable: yes

hls:
enable: yes
segmentCount: 7
segmentDuration: 2s
partDuration: 0

🧪 O mistério do LL-HLS

Mesmo após tudo parecer configurado corretamente, notei um comportamento estranho: o player apresentava travamentos e alto uso de CPU. Depois de horas investigando, descobri que o modo LL-HLS (Low-Latency HLS) vinha ativado por padrão no MediaMTX.

Esse modo não se adequava à minha infraestrutura e gerava gargalos sérios.

A solução foi explícita:

hls:
variant: mpegts

Forçar o modo clássico de segmentação (mpegts) fez o LL-HLS sumir!

"HLS listener opened on :8888"

sem erros, foi um alívio indescritível.

No próximo post, explico como configurei o FFPlayout para transmitir os vídeos e como usei Nginx como proxy reverso — incluindo as dores (e soluções) com CORS e HTTPS.

Criando um Servidor de Streaming 24/7: Parte 1 - Infraestrutura Inicial

Matheus Torres — Sat, 31 May 2025 17:14:22 +0000

Criando um Servidor de Streaming 24/7: Parte 1 - Infraestrutura Inicial

Este é o primeiro post de uma série sobre como criei, passo a passo, um servidor completo de streaming 24/7, usando FFPlayout, MediaMTX e Nginx. Além da parte técnica, compartilho também os desafios reais e aprendizados que surgiram durante o processo.

🚩 A ideia inicial e escolha da VPS

Tudo começou com uma tarefa aparentemente simples: colocar no ar um canal de TV online para transmitir conteúdos pré-gravados e eventualmente fazer transmissões ao vivo. Eu já tinha experiência com edição de vídeos e conhecia o básico do FFPlayout, mas nunca havia montado um servidor completo, muito menos configurado um serviço de streaming do zero.

Meu primeiro grande desafio foi escolher a infraestrutura. Inicialmente testei algumas opções na AWS, mas logo percebi que o custo para manter portas abertas e garantir performance ficaria acima do meu orçamento inicial.

Depois de pesquisar bastante, encontrei uma opção acessível na Contabo com as seguintes especificações:

6 vCPUs
12 GB RAM
500 GB SSD

Era exatamente o que eu precisava para ter liberdade de experimentar sem me preocupar com custos inesperados.

🔥 Desbravando o Ubuntu

Instalei o Ubuntu Server 22.04 LTS e parti para a configuração inicial, que envolveu abrir portas específicas no firewall:

sudo ufw allow 1935/tcp   # RTMP
sudo ufw allow 8888/tcp   # HLS
sudo ufw allow 8890/udp   # SRT
sudo ufw enable

Essas portas seriam essenciais para o funcionamento dos protocolos que eu pretendia usar (RTMP, HLS e SRT).

Aprendi também a usar systemd para criar serviços que mantivessem meus aplicativos rodando automaticamente após reinicializações do servidor. Foi uma experiência nova e, de certa forma, assustadora lidar com arquivos de serviço e permissões pela primeira vez.

Exemplo básico da criação do serviço para o MediaMTX:

[Unit]
Description=MediaMTX Streaming Server
After=network.target

[Service]
User=stream
ExecStart=/usr/local/bin/mediamtx /etc/mediamtx/mediamtx.yml
Restart=always

[Install]
WantedBy=multi-user.target

📌 Primeiros aprendizados

Cada pequeno erro gerava um aprendizado, e cada vitória, uma celebração pessoal. Rapidamente percebi que escolher o provedor certo (no meu caso, a Contabo) fez toda a diferença no quanto eu pude explorar e aprender sem barreiras.

Essa primeira fase, apesar de ser apenas a fundação, foi crucial para tudo o que veio a seguir.

No próximo post, conto como enfrentei o desafio do MediaMTX, incluindo problemas complicados com YAML e configurações padrão que quase sabotaram todo o projeto.