
Você já se deparou com aquela situação onde o banco de dados está lento e você precisa descobrir qual consulta está causando o problema? Ou então precisou cancelar uma query que travou e está consumindo recursos do servidor? 

Se você trabalha com PostgreSQL, conhecer as ferramentas de monitoramento de consultas é essencial. Neste artigo, vou compartilhar algumas técnicas que uso no dia a dia para identificar e gerenciar consultas em execução.

## A view pg_stat_activity

O PostgreSQL possui uma view chamada `pg_stat_activity` que é uma verdadeira mão na roda para quem precisa monitorar o que está acontecendo no banco. Ela fornece informações sobre todas as conexões ativas e as consultas que estão sendo executadas.

### Visualizando todas as consultas em execução

Para ver todas as queries que estão rodando neste momento, você pode usar:

```sql
SELECT pid, usename, query_start, state, query 
FROM pg_stat_activity 
WHERE state = 'active' 
  AND pid <> pg_backend_pid();
```

O filtro `pid <> pg_backend_pid()` serve para excluir a própria consulta que estamos executando do resultado.

### Identificando consultas lentas

Uma das situações mais comuns é precisar encontrar aquela consulta que está demorando mais do que deveria. Para isso, podemos ordenar pelo tempo de execução:

```sql
SELECT 
    pid, 
    usename, 
    query_start, 
    now() - query_start AS duration, 
    state, 
    query 
FROM pg_stat_activity 
WHERE state = 'active' 
  AND pid <> pg_backend_pid() 
ORDER BY duration DESC;
```

### Filtrando consultas por tempo de execução

Se você quer ver apenas as consultas que estão rodando há mais de um minuto (geralmente um sinal de alerta), use:

```sql
SELECT 
    pid, 
    usename, 
    query_start, 
    now() - query_start AS duration, 
    state, 
    query 
FROM pg_stat_activity 
WHERE state = 'active' 
  AND now() - query_start > interval '1 minute' 
ORDER BY duration DESC;
```

## Gerenciando consultas problemáticas

Encontrou a consulta problemática? Agora você tem duas opções para lidar com ela:

### Cancelar uma consulta

A forma mais "gentil" de interromper uma consulta é usando `pg_cancel_backend`:

```sql
SELECT pg_cancel_backend(12345);
```

Substitua `12345` pelo PID da consulta que você identificou anteriormente. Essa função envia um sinal de cancelamento para a query, permitindo que ela termine de forma controlada.

### Encerrar uma conexão forçadamente

Se o cancelamento não funcionar (às vezes a query está em um estado que não responde ao sinal), você pode forçar o encerramento da conexão:

```sql
SELECT pg_terminate_backend(12345);
```

⚠️ **Atenção:** Use esta opção com cuidado, pois ela encerra a conexão inteira, não apenas a consulta. Qualquer transação em andamento será revertida.

## Dica bônus: Identificando consultas por comentário

Uma prática que adotei em projetos é adicionar comentários identificadores nas queries da aplicação. Isso facilita muito na hora de rastrear qual parte do sistema está gerando determinada consulta:

```sql
SELECT pid, usename, query_start, state, query 
FROM pg_stat_activity 
WHERE query ILIKE '%/* ModuloPedidos */%' 
  AND state = 'active';
```

Dessa forma, você consegue filtrar rapidamente todas as consultas de um módulo específico.

## Considerações finais

Monitorar consultas é fundamental para manter a saúde do seu banco de dados. Essas técnicas são simples, mas extremamente úteis no dia a dia. Lembre-se de que você precisa ter as permissões adequadas para visualizar consultas de outros usuários e para cancelá-las.

Espero que essas dicas sejam úteis para você! Se tiver alguma dúvida ou quiser compartilhar outras técnicas, fique à vontade para entrar em contato.


Aprenda a identificar, monitorar e gerenciar consultas em execução no PostgreSQL. Técnicas essenciais para manter a saúde do seu banco de dados.

📃 Monitorando Consultas no PostgreSQL

# Arquitetura Hexagonal

A Arquitetura Hexagonal consiste em dividir em camadas as classes de um sistema, onde as regras de negócio e entidades ficam na camada principal, a de Domínio, dessa forma é possível garantir a integridade da aplicação, reutilização das regras de negócio para diversas plataformas como web e mobile além da fácil substituição de tecnologias externas como banco de dados devido à falta de dependências de framework.

![Arquitetura Hexagonal](/images/hexagonal.svg)

## Adaptadores e portas

Com a camada de Domínio sendo a camada principal da arquitetura, é importante que ela esteja isolada e seja acessada de forma restrita por ferramentas externas, dessa maneira as formas de comunicação entre outras camadas e a camada de Domínio se dá via Adaptadores.

![Adaptadores](/images/hexagonal-adapters1.svg)

Adaptadores atuam se comunicando com as portas, para que haja comunicação interna e externa da aplicação. Uma porta (interface) é uma especificação de como o domínio pode ser utilizado, ou seja, para entrada ou saída da aplicação:

- Porta de Entrada (Input) são as interfaces utilizadas para comunicação de fora para dentro do Hexágono, 
- Porta de Saída (Output) a comunicação de dentro para fora do domínio, como banco de dados, retorno de APIs e etc.

É importante ressaltar que as Portas pertencem a lógica de negócio, ou seja, as portas são independentes de tecnologia. Enquanto os Adaptadores pertencem a parte externa da camada, normalmente utilizando alguma tecnologia, seja de comunicação (como API Rest), banco de dados (como SQL Server) ou interação de usuários.


![Adaptadores e Portas](/images/hexagonal-adapters.svg)

Os adaptadores podem receber requisições de métodos tanto fora do sistema quanto vindas de dentro do sistema, é possível que o mesmo adaptador que envio uma requisição para o domínio também receba um retorno do mesmo domínio dessa forma podendo exibir uma mensagem de retorno HTTP por exemplo.

Devido ao foco dessa arquitetura estar em portas e adaptadores para acessar o domínio houve uma tentativa de renomeação para Arquitetura baseada em Portas e Adaptadores.

![Arquitetura Completa](/images/hexagonal-complete.svg)

A vantagem principal está que arquitetura hexagonal consegue manter a integridade da aplicação construindo um projeto com **independência de tecnologias**, favorecendo a **reusabilidade de código**, baixo acoplamento, **alta coesão e fácil de ser testado**.





Descubra como a Arquitetura Hexagonal transforma o design de software, trazendo benefícios práticos para seu projeto. Explore sua eficácia e aplicação neste estudo aprofundado.

📃 Arquitetura Hexagonal


# Arquitetura de Integração

A arquitetura de integração refere-se à estrutura e design de sistemas que facilitam a comunicação e a interação entre diferentes componentes de software, sistemas ou aplicações. É importante se ter em mente que um sistema de grande porte não vive de maneira isolada, de forma que um sistema sempre se comunicará com demais sistemas diferentes entre si. Essa comunicação pode ocorrer de diversas formas como: sincronizando dados com outros sistemas e garantindo que todas as informações estejam coesas em todos os lados, **seja um sistema local, de nuvem ou sistemas de terceiros.**

Dessa maneira surge a arquitetura de integração, como uma forma de estabelecer formatos e mecanismos que evite ao máximo a latência com a qual os dados serão disponibilizados entre os sistemas, assim como independência de cada serviço nessa rede de conexões. Em alguns casos, para ocorrer a integração é necessário a chamada de uma API, em outros, as tecnologias precisam de uma comunicação assíncrona, necessitando de algo como mensagens ou eventos.


Todos os processos precisam de sua devida orquestração, ou seja, independente de tecnologia envolvidas na integração, é necessário um planejamento visando uma maneira simples de garantir os fluxos e execução do modelo de negócio.


Elementos técnicos que consistem na arquitetura:

- Padrões de comunicação, como HTTP, HTTPS, SOAP, REST;
- ESB (Enterprise Service Bus);
- Protocolos de segurança SSL/TLS;
- APIs;
- Sistemas de mensageria, como Apache Kafka ou RabbitMQ;
- Bancos de dados ou armazenamento de dados;
- Ferramentas de monitoramento e análise;

O maior benefício dessa arquitetura é que se torna possível enxergar todas as integrações de forma macro, sendo uma arquitetura baseada em “contêiners”, onde cada serviço cumpre a sua função, com isso é possível:

- **Maior agilidade**: com a visão de arquitetura de integração se torna viável trabalhar com microsserviços, por ser interessante que cada software tenha suas próprias funções isoladas, mantendo um código de fácil manutenção e de fácil leitura.
- **Escalabilidade**: os recursos podem ser ajustados de acordo com o modelo de negócios, possuindo uma maior flexibilidade para lidar com o aumento ou diminuição de cargas de trabalho com mínimo impacto.
- **Resiliência**: como cada software possui a sua própria independência na visão geral da arquitetura de integração, é possível garantir um rápido desacoplamento e qualquer mudança não afeta os demais serviços que já estão em execução.

Além de poder se relacionar com as demais arquiteturas com interdependência. Exige da organização conhecimento prévio das necessidades e requisitos de seu próprio negócio e todas as possíveis integrações.


Empresas que aplicam cases de arquitetura de integração em suas soluções:

**Amazon**: A empresa utiliza a arquitetura de integração para integrar seus diversos serviços e plataformas, como o Amazon Web Services (AWS) e o Amazon Marketplace.

**Uber**: A Uber utiliza a arquitetura de integração para integrar seus aplicativos e serviços, permitindo que os usuários solicitem e paguem por corridas por meio de vários canais, como o aplicativo da Uber, assistentes virtuais e outros aplicativos de terceiros.

**Airbnb**: A Airbnb utiliza a arquitetura de integração para integrar seus aplicativos e serviços, permitindo que os usuários reservem acomodações por meio de diferentes canais, como o site da Airbnb, aplicativos de terceiros e assistentes virtuais.

**Walmart**: O Walmart implementou uma arquitetura de integração baseada em APIs para conectar seus sistemas de compras online e em lojas físicas. A arquitetura de integração permitiu que o Walmart oferecesse aos clientes uma experiência de compras mais integrada e personalizada.

**American Airlines**: A American Airlines implementou uma arquitetura de integração baseada em barramento de serviços para integrar seus sistemas de reserva, check-in e bagagem. A arquitetura de integração permitiu que a American Airlines melhorasse a eficiência de seus processos de negócios e oferecesse uma experiência de viagem mais integrada e personalizada para seus clientes.

Esses são apenas alguns exemplos de casos de sucesso de arquitetura de integração. A escolha da arquitetura de integração mais adequada deve levar em consideração as necessidades específicas de cada empresa e dos sistemas envolvidos.




A arquitetura de integração refere-se à estrutura e design de sistemas que facilitam a comunicação e a interação entre diferentes componentes de software, sistemas ou aplicações.

📃 Arquitetura de Integração


Sessão de bate-papo ao vivo, com intuito de sanar suas dúvidas sobre o início de carreira como Desenvolvedor.

<Bleed>
<iframe width="560" height="315" src="https://www.youtube.com/embed/_roQviwNh9M?si=RqaJe1bouWptDMNC&amp;controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
</Bleed>


Sessão de bate-papo ao vivo, com intuito de sanar suas dúvidas sobre o início de carreira como Desenvolvedor.

📺 Live - Tirando dúvidas sobre o início de carreira como Desenvolvedor!


Nessa live apresentamos os principais recursos da linguagem mais utilizada para desenvolvimento de aplicativos Android.

<Bleed>
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/4TnoeXqTClE?si=Wg_7GG-AnS6o4Vco&amp;controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
</Bleed>


Nessa live apresentamos os principais recursos da linguagem mais utilizada para desenvolvimento de aplicativos Android.

📺 Live - Hello Kotlin | Aprenda o Desenvolvimento na plataforma Android utilizando Kotlin e Android Studio


# S.O.L.I.D
<hr>

**SOLID** é um acrônimo criado por Michael Feathers, para os cinco princípios que julgou os mais utilizados na Programação Orientada a Objetos e design de código. Estes princípios, foram abordados inicialmente por Robert C. Martin — o famoso Uncle Bob — em seu artigo “Os princípios de Design Orientado a Objetos”.

Cada princípio traz uma abordagem e maneira de desenvolver códigos mais limpos e coesos, podendo ser utilizado e aplicado em qualquer linguagem de programação orientada a objetos. Nos tópicos abaixo, serão exemplificados cada princípio e sua função.


**S** – Single Responsibility Principle (Princípio da Responsabilidade Única)
**O** – Open-Closed Principle (Princípio Aberto-Fechado)
**L** – Liskov Substitution Principle (Princípio da Substituição de Liskov)
**I** – Interface Segregation Principle (Princípio da Segregação da Interface)
**D** – Dependacy Inversion Principle (Princípio da Inversão das Dependências)



## Single Responsibility Principle (SRP)
<hr>


**Princípio da Responsabilidade Única** — Uma classe deve ter um, e somente um, motivo para mudar.

O princípio da responsabilidade única deixa claro que uma classe deve ser especializada somente em uma tarefa, ou seja, somente uma responsabilidade dentro do sistema, dessa maneira a classe só possuirá um motivo para que seja feito alguma alteração.

O termo utilizado para classes com muitas responsabilidades é o God Class (Classe Deus) e deve ser evitado pela difícil manutenção, por conta de os perigos de modificação poder comprometer as outras tarefas executadas pela mesma classe além da complexidade de reaproveitamento de código.

Quando criado classes para o sistema, idealmente é imaginado quais possibilidades e funções poderão executar. Nos errôneos casos, esta classe terá diversas responsabilidades para se preocupar.

Digamos que exista uma classe que representa um retângulo, com propriedades da sua área. O retângulo se preocupará em manter sua área, mas também em desenhá-la, como na imagem abaixo:


![image.png](/.attachments/image-e6716a03-677e-4d30-be79-015bc6b492a9.png)

Se um dia precisarmos alterar o modo de desenharmos a área do retângulo, será preciso precisar modificar a classe. Qualquer nova alteração irá gerar manuseio e modificação da classe Rectangle, que consequentemente os demais módulos que a usam, deverão ser revisados e testados.

Seguindo o princípio SRP, a classe Rectangle deverá se preocupar apenas com a sua área. Desta maneira deverá ser externalizado para outra classe a função de desenhar, como na imagem abaixo:


![image.png](/.attachments/image-0905a6b9-e77e-4005-929c-7d943ff721ff.png)


Com isto, o uso da classe Rectangle passa a ser descartado de modificações, apenas gerando alteração na única, e somente uma, funcionalidade.

Possíveis problemas de violação do princípio SRP:

- Falta de coesão;
- Alto acoplamento;
- Dificuldades com testes automatizados;
- Reaproveitamento de código.


## Open-Closed Principle (OCP)
<hr>

**Princípio Aberto-Fechado** — Objetos ou entidades devem estar abertos para extensão, mas fechados para modificação.

O princípio de Aberto-Fechado diz que você pode ser capaz de estender um objeto ou entidade, mas os mesmos devem ser fechados para modificações. Ou seja, para adição de novas funcionalidades ou comportamentos dos sistemas, é esperado que a entidade seja estendida e não alterado diretamente.

O pensamento, de **separar o comportamento extensível por trás de uma interface e inverter as dependências** foi idealizado pelo Uncle Bob, com o intuito de concentrar tudo que seja possivelmente modificado e que tenha tendência de crescimento, em interfaces, assim sendo possível a inversão da dependência no código.

Imagine que exista uma classe FolhaPagamento que realiza o fechamento, e recebe os funcionários para cálculo do pagamento. Para que a lógica funcione, ela deverá fazer uma validação do tipo de contrato, e executar o método que contabiliza o valor a ser pago. Como na imagem abaixo:

![image.png](/.attachments/image-ba243273-3744-4c58-917f-62e2e37cc129.png)

Seguindo por este lado, quando a empresa precisar adicionar um novo meio de contrato, por exemplo um PJ, será alterado a classe FolhaPagamento para uma nova validação e busca do método correto com a somatória do valor. Esta abordagem fere o OCP, pois a classe está aberta para modificações.

Um dos melhores cenários a se trabalhar para mitigar o problema, é criando uma interface para remuneração, onde existirá somente um método que será chamado e implementado pelas classes de contrato. Como no exemplo abaixo:

![image.png](/.attachments/image-dc4185fd-3569-418b-b398-501f47752eb4.png)


## Liskov Substitution Principle (LSP)
<hr>

O princípio de substituição de Liskov diz que uma classe derivada pode ser substituída por sua classe base sem que isso afete a execução correta do programa. 
Com esse princípio podemos aplicar o Polimorfismo para sempre utilizar as classes derivadas fazendo a devida referência à classe base garantindo a solidez do sistema.


## Interface Segregation Principle (ISP)
<hr>

O princípio da segregação da interface diz que uma classe não deve possuir métodos e interface que não serão utilizadas, ou seja é melhor termos interfaces mais especificas para sua funcionalidade do que interfaces genéricas, dessa forma a classe não é forçada a implementar métodos que não serão utilizados por ela.

## Dependency Inversion Principle (DIP)
<hr>

O princípio da inversão de dependência afirma que devemos depender mais de abstrações do que implementações. Dessa forma evitamos ao máximo acoplamento, podendo aproveitar o código em outros sistemas, sem a necessidade de trazer as dependências junto a classe, a forma correta é utilizar Injeção de Dependências via método.


Em conclusão, os princípios S.O.L.I.D oferecem uma abordagem robusta e orientada a objetos para o desenvolvimento de software, promovendo a criação de código flexível, escalável e de fácil manutenção. Ao aderir a esses princípios — Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation e Dependency Inversion — os desenvolvedores podem criar sistemas mais resilientes às mudanças, menos propensos a erros e mais fáceis de entender e expandir.

Este artigo explora de forma acessível os fundamentos dessa abordagem para design de software. Aprenda e aplique esses princípios para um código mais robusto e flexível.

📃 O que é S.O.L.I.D?


O levantamento de requisitos serve para identificarmos as necessidades e possíveis problemas dos usuários, por tanto toda regra de negócio pode ser chamada de requisito também.

Essa etapa é essencial para mapearmos a realidade do usuário, então é extremamente importante a **clareza** e **objetividade** de cada requisito. Tenha em mente que assim que os requisitos forem levantados, todas as etapas seguintes do processo de desenvolvimento do sistema serão baseadas nesse documento.

Os requisitos podem ser classificados de duas formas:

**Requisitos Funcionais:**  tratam o comportamento do sistema da forma que o usuário deseja, descrevendo como a aplicação deve se comportar em determinadas situações.

Como por exemplo:
* “O sistema terá que conter um input para buscas”
* “O aplicativo deverá ter um formulário para cadastro”
* O usuário poderá alterar as informações do cadastro”

**Requisitos Não Funcionais:** descrevem como a aplicação será desenvolvida, ou seja, os recursos necessários para colocarmos os requisitos funcionais em prática, estando ligado a características do aplicativo ou restrições.

Como por exemplo:
   - “O aplicativo contará com uma base de dados Azure SQL Database para armazenamento dos dados do usuário”
   - “O formulário para cadastro será feito em HTML e Javascript”

É essencial nessa primeira parte que sejam realizadas algumas entrevistas com o cliente para um entendimento geral do projeto, entendimento do cenário atual do usuário, as principais expectativas do cliente, todas as possíveis restrições do projeto e o que é realmente necessário para a aplicação.

**Tenha em mente que apenas uma reunião pode não ser o suficiente para levantar todos os requisitos necessários para o sistema.**

Algumas dicas de como seguir durante as entrevistas de forma que os requisitos possam surgir de forma coerente:


* Procure manter sempre a mente aberta;
* Deixei que o usuário tenha espaço para trazer a sua visão do projeto;
* Esteja preparado para mudanças nessa fase de levantamento;
* Traga as suas dúvidas ou monte um roteiro de entrevista;
* Anote o máximo de informações que conseguir;

Documentação
---------------------
---

Separe os requisitos entre duas tabelas, uma para os requisitos funcionais (RN) e o outra para os requisitos não-funcionais (RNF).

É importante notar que cada requisito deve ser validado preenchendo alguns critérios como:

* Ser necessário para aplicação;
* Ser claro, de forma que não haja espaço para dupla interpretação;
* Capaz de ser atingível, ou seja, que o time de desenvolvimento seja capaz de executá-lo
* Possuir conexão entre os demais requisitos;

A seguir um exemplo de como organizar os requisitos funcionais e não-funcionais de uma simples tela de login e cadastramento:       

**Requisitos Funcionais**

* RQ01: O aplicativo deverá permitir que o usuário acesse a aplicação com Nome de Usuário e Senha.
* RQ02: O aplicativo deve permitir que o usuário se cadastre na aplicação com os seguintes campos na tela de cadastro:
        Email;
        Nome do Usuário;
        RG
        Senha
        Confirmação de senha;
* RQ03: O aplicativo deve permitir que o usuário altere as suas informações de cadastro, criadas no RQ02, exceto pelo campo de RG.

**Requisitos Não-Funcionais**

* RNF01: Os dados do usuário devem ser armazenados em um banco de dados SQL.

Depois de escrito os requisitos, a várias formas de agrupá-los de acordo com a sua importância para o sistema.

Uma dessa formas é separar os requisitos por Critérios, dessa forma os requisitos podem ser classificados em três formas:

**Requisitos Essenciais:** Extremamente importante para o sistema, relacionado diretamente as necessidades ou problemas do usuário.  Se não implementados a aplicação não pode ser concluída.

**Requisitos Importantes:** Embora não seja de fato o mais importante e não impede que a aplicação entre em produção, caso não esteja implementado dará prejuízos ao negócio.

**Requisitos Desejáveis:** Não trará nenhum prejuízo para o negócio, porém é algo que o cliente gostaria que fosse implementado, então deve-se dar atenção também.

Outra forma de agrupar os requisitos é por prioridade, definindo prioridade entre alta, média ou baixa de cada requisito com a seguinte pergunta: “O que é considerado mais importante para o usuário no sistema?”

Validação
---------------------
---
A validação com o usuário é a última parte de levantamentos de requisitos, é aqui que o usuário revisa todos os requisitos documentados, é esclarecido e verificado cada requisito.  Essa verificação é útil para validar se os requisitos são realmente necessários, se não possui nenhum conflito entre eles, se estão atendendo todas as restrições e se podem ser realmente implementados pelo time.

Esteja atento que nessa etapa, alguns requisitos podem ser alterados ou novos requisitos também podem surgir durante o debate com o usuário.

Por último, depois de todas as correções caso necessário, o aval do cliente de que os requisitos levantados realmente atentem as suas necessidades e expectativas.

Depois da documentação estar finalizada e aprovada, podemos seguir para um Protótipo seguindo todos os nossos requisitos levantados. Mas isso é assunto para outro artigo. 😁

Obrigado por ler até aqui!


Nesse artigo darei algumas dicas e formas para levantar os requisitos necessários para o desenvolvimento de um sistema, o desenvolvimento desse documento acompanhará todas as etapas adjacentes do desenvolvimento por tanto é crucial entender as necessidades do usuário.

📃 Sobre Levantamento de Requisitos


Neste episódio vamos conversar como o aumento da informação fez com que as ideias revolucionárias sejam cada vez mais frequentes.

Pauta

* Introdução;
* Comunicação e Informação antigamente, Conexão Entre como PESSOAS;
* Como foram as ideias revolucionárias tecnológicas e seus impactos;
* Como hoje em dia são as ideias e como podem se tornar futuramente na sociedade.

Participantes

- Willians Tavares 
- Jefferson Almeida 
- Eduardo Bolize 
- Pablo Luiz 

<iframe class="podcast" src="https://open.spotify.com/embed/episode/5MDoucC7IDIvZUoFDog6gr?utm_source=generator" width="100%" height="152" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>

Neste episódio vamos conversar como o aumento da informação fez com que as ideias revolucionárias sejam cada vez mais frequentes.

🎙️Podcast - Ideias revolucionárias com o aumento da informação.


Vamos discutir sobre cada linguagem de programação e onde ela se enquadra nos rankings criados, depois teremos mais uma criação da Tier List mas com base nas opiniões do chat.

<Bleed>
<iframe width="560" height="315" src="https://www.youtube.com/embed/2LWGWKLLfKg?si=Cv83fVssQR39niIU&amp;controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
</Bleed>


Live sobre linguagens de programação no geral.

📺 Live - Linguagens de programação (Tier List)


Nesse episódio conversaremos sobre Clean Code, sua importância e relevância no mercado. Vamos bater um papo sobre experiências reais da nossa equipe técnica no assunto.

Pauta

* Introdução; 
* Importância no dia-a-dia;
* Experiências reais;
* Relevância do clean code;
* Referências do clean code;

Participantes

- Euripedes de Souza 
- Willians Tavares 
- Jefferson Almeida 
- Eduardo Brandão 


<iframe class="podcast" src="https://open.spotify.com/embed/episode/180zifPzCFpdwBVSQxDCnu?utm_source=generator&theme=0" width="100%" height="152" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>

Nesse episódio conversaremos sobre Clean Code, sua importância e relevância no mercado. Vamos bater um papo sobre experiências reais da nossa equipe técnica no assunto.

🎙️ Podcast - Clean Code


Neste episódio conversaremos sobre o mundo de desenvolvimento e como montar ou se organizar para planejar um estudo de carreira, confira a conversa e compartilhe sua experiência conosco.

Pauta:

* Perfis de desenvolvimento
    * Front
    * Back
    * Mobile
    * QA
* Perfil do desenvolvedor, como encontrar o seu?
* Cursos, certificações, graduação...
* Qual a importância de ser autodidata trabalhando em casa
* Conclusão / Considerações finais.

<iframe class="podcast" src="https://open.spotify.com/embed/episode/6cxPria847HOOLo5aTr6zG?utm_source=generator" width="100%" height="352" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>


Neste episódio conversaremos sobre o mundo de desenvolvimento e como montar ou se organizar para planejar um estudo de carreira, confira a conversa e compartilhe sua experiência conosco.