
# Introdução: O Poder e o Perigo da Concorrência em Go

Go brilha quando o assunto é concorrência. Com sua sintaxe simples e o poderoso conceito de *goroutines* e *channels*, criar programas que executam múltiplas tarefas simultaneamente torna-se incrivelmente acessível. Goroutines são funções ou métodos que rodam concorrentemente com outras funções ou métodos. São leves, permitindo que você execute milhares, até milhões delas, em uma única aplicação.

No entanto, essa facilidade traz consigo responsabilidades. Um dos anti-patterns mais comuns e perigosos ao trabalhar com concorrência em Go é o uso inadequado de variáveis globais compartilhadas entre múltiplas goroutines. Embora possam parecer convenientes à primeira vista, elas são uma receita quase certa para dores de cabeça, bugs difíceis de rastrear e comportamento imprevisível.

Neste artigo, vamos explorar por que você deve pensar duas (ou três!) vezes antes de usar variáveis globais em seus programas Go concorrentes e quais alternativas mais seguras e robustas existem.

## O Problema Central: Condições de Corrida (Race Conditions)

O principal vilão ao compartilhar variáveis globais entre goroutines sem a devida sincronização é a **condição de corrida (race condition)**.

Uma race condition ocorre quando:

1.  Múltiplas goroutines acessam o mesmo recurso compartilhado (neste caso, uma variável global).
2.  Pelo menos uma dessas goroutines está *modificando* o recurso.
3.  Não há sincronização explícita para controlar o acesso a esse recurso.

O resultado? A ordem de execução das operações de leitura e escrita torna-se não determinística, dependendo de como o scheduler do Go decide executar as goroutines. Isso leva a resultados inconsistentes e muitas vezes incorretos, que podem variar a cada execução do programa.

Imagine duas goroutines tentando incrementar um contador global `contador := 0` ao mesmo tempo:

*   Goroutine A lê `contador` (valor 0).
*   Goroutine B lê `contador` (valor 0).
*   Goroutine A calcula `0 + 1 = 1`.
*   Goroutine B calcula `0 + 1 = 1`.
*   Goroutine A escreve `1` em `contador`.
*   Goroutine B escreve `1` em `contador`.

Esperávamos que o resultado fosse 2, mas devido à race condition, o resultado final é 1.

### Exemplo Prático (Problemático)

Vamos ver um exemplo de código que demonstra esse problema:

```go
package main

import (
	"fmt"
	"sync"
	"time"
)

// Variável global compartilhada
var contadorGlobal int

func main() {
	var wg sync.WaitGroup
	numeroDeGoroutines := 1000

	wg.Add(numeroDeGoroutines)

	for i := 0; i < numeroDeGoroutines; i++ {
		go func() {
			defer wg.Done()
			// Operação não atômica que causa a race condition
			valorAtual := contadorGlobal
			// Pequeno delay para aumentar a chance da race condition ocorrer
            time.Sleep(time.Microsecond)
			valorAtual++
			contadorGlobal = valorAtual
		}()
	}

	wg.Wait() // Espera todas as goroutines terminarem

	fmt.Printf("Valor final esperado (teoricamente): %d\n", numeroDeGoroutines)
	fmt.Printf("Valor final real do contador: %d\n", contadorGlobal)
}
```

Se você executar este código (`go run main.go`), notará que o "Valor final real do contador" raramente (ou nunca) será 1000. O valor será inconsistente a cada execução.

**Detectando Race Conditions:** Felizmente, Go possui uma ferramenta integrada para detectar race conditions. Execute o código com a flag `-race`:

```bash
go run -race main.go
```

Você provavelmente verá um aviso como `WARNING: DATA RACE`, indicando exatamente onde as leituras e escritas conflitantes estão ocorrendo.

### Impactos Negativos do Uso de Globais com Goroutines

Além das race conditions óbvias, usar variáveis globais em cenários concorrentes traz outros problemas:

1.  **Resultados Imprevisíveis:** Como vimos, o estado final da variável é incerto.
2.  **Debugging Dificultado:** Race conditions são notoriamente difíceis de depurar porque são sensíveis ao timing e podem não ocorrer consistentemente.
3.  **Manutenibilidade Reduzida:** O estado global torna o código mais difícil de entender e raciocinar sobre. Não fica claro quais partes do código podem modificar a variável, tornando refatorações e adições de features mais arriscadas.
4.  **Testabilidade Comprometida:** Testes unitários tornam-se mais complexos, pois o estado global pode vazar entre testes ou exigir configurações complicadas para isolar o componente sendo testado.

### Alternativas Seguras e Idiomáticas

Felizmente, Go oferece mecanismos excelentes para gerenciar estado compartilhado de forma segura em ambientes concorrentes.

**1. Passagem Explícita de Variáveis (Preferível)**

A maneira mais idiomática e geralmente mais segura é evitar o estado compartilhado global sempre que possível. Em vez disso, passe os dados necessários como parâmetros para as goroutines e retorne resultados através de canais ou outros meios.

```go
package main

import (
	"fmt"
	"sync"
	"sync/atomic" // Pacote para operações atômicas
)

func worker(id int, contador *int64, wg *sync.WaitGroup) {
	defer wg.Done()
	// Operação atômica segura para incrementar
	atomic.AddInt64(contador, 1)
	// fmt.Printf("Worker %d incrementou\n", id) // Opcional
}

func main() {
	var contador int64 // Usando int64 para compatibilidade com atomic
	var wg sync.WaitGroup
	numeroDeGoroutines := 1000

	wg.Add(numeroDeGoroutines)

	for i := 0; i < numeroDeGoroutines; i++ {
		// Passando o ponteiro do contador para a goroutine
		go worker(i, &contador, &wg)
	}

	wg.Wait()

	fmt.Printf("Valor final esperado: %d\n", numeroDeGoroutines)
	fmt.Printf("Valor final real do contador: %d\n", contador)
}
```

Neste exemplo (usando `sync/atomic` para segurança na incrementação), passamos um ponteiro para o contador, tornando a dependência explícita. Note que mesmo passando um ponteiro, a *operação* em si precisa ser segura para concorrência (daí o uso de `atomic.AddInt64`).

**2. Operações Atômicas (`sync/atomic`)**

Para operações simples como incremento, decremento e substituição de valores, o pacote `sync/atomic` oferece funções que garantem a atomicidade sem a necessidade de mutexes explícitos:

```go
package main

import (
	"fmt"
	"sync"
	"sync/atomic"
)

func main() {
	var contador int64 // Usando int64 para compatibilidade com atomic
	var wg sync.WaitGroup
	numeroDeGoroutines := 1000

	wg.Add(numeroDeGoroutines)

	for i := 0; i < numeroDeGoroutines; i++ {
		go func() {
			defer wg.Done()
			// Operação atômica - incremento seguro sem mutex
			atomic.AddInt64(&contador, 1)
		}()
	}

	wg.Wait()

	fmt.Printf("Valor final esperado: %d\n", numeroDeGoroutines)
	fmt.Printf("Valor final real do contador: %d\n", contador)
}
```

Esta abordagem é mais eficiente que usar mutexes para operações simples, pois evita o bloqueio completo, usando instruções específicas do processador para garantir a atomicidade.

**3. Canais (Channels)**

Canais são a forma preferida em Go para comunicação *entre* goroutines. Eles podem ser usados para passar dados ou para sincronizar a execução.

*"Não comunique compartilhando memória; em vez disso, compartilhe memória comunicando."* - Effective Go

```go
package main

import (
	"fmt"
	"sync"
)

func main() {
	numeroDeGoroutines := 1000
	requests := make(chan bool) // Canal para enviar "pedidos" de incremento
	done := make(chan bool)     // Canal para sinalizar o fim
	var wg sync.WaitGroup      // WaitGroup para garantir que todas as goroutines trabalhadoras terminem

	// Goroutine para gerenciar o contador centralmente
	go func() {
		contador := 0
		for i := 0; i < numeroDeGoroutines; i++ {
			<-requests // Espera um pedido
			contador++
		}
		fmt.Printf("Valor final real do contador: %d\n", contador)
		done <- true // Sinaliza que terminou
	}()

	// Lança as goroutines "trabalhadoras"
	wg.Add(numeroDeGoroutines)
	for i := 0; i < numeroDeGoroutines; i++ {
		go func() {
			defer wg.Done()
			requests <- true // Envia um pedido de incremento
		}()
	}

	// Espera todas as goroutines trabalhadoras terminarem
	wg.Wait()

	// Espera a goroutine gerenciadora terminar
	<-done
	fmt.Printf("Valor final esperado: %d\n", numeroDeGoroutines)
}
```

Neste modelo, apenas uma goroutine modifica o estado, e as outras se comunicam com ela através de um canal, eliminando a race condition.

**4. Primitivas de Sincronização (`sync` package)**

Se você *realmente* precisa compartilhar memória (talvez por razões de performance ou estrutura de dados complexa), use as primitivas de sincronização do pacote `sync`, como `sync.Mutex` ou `sync.RWMutex`.

Um `Mutex` (Mutual Exclusion) garante que apenas uma goroutine possa acessar a seção crítica (o código que modifica a variável compartilhada) por vez.

```go
package main

import (
	"fmt"
	"sync"
)

var contadorGlobal int
var mutex sync.Mutex // Mutex para proteger o contadorGlobal

func incrementarContador() {
	// Bloqueia o mutex antes de acessar a variável global
	mutex.Lock()
	// --- Seção Crítica ---
	contadorGlobal++ // Incremento direto
	// --- Fim da Seção Crítica ---
	mutex.Unlock() // Libera o mutex
}

func main() {
	var wg sync.WaitGroup
	numeroDeGoroutines := 1000

	wg.Add(numeroDeGoroutines)

	for i := 0; i < numeroDeGoroutines; i++ {
		go func() {
			defer wg.Done()
			incrementarContador()
		}()
	}

	wg.Wait()

	fmt.Printf("Valor final esperado: %d\n", numeroDeGoroutines)
	fmt.Printf("Valor final real do contador: %d\n", contadorGlobal)
}
```

Este código agora produzirá o resultado correto (1000), pois o acesso à `contadorGlobal` está protegido pelo `mutex`. No entanto, o uso excessivo de mutexes pode levar a contenção e gargalos de performance, além de introduzir a possibilidade de *deadlocks* se não forem usados corretamente.

### Quando Variáveis Globais *Podem* Ser Aceitáveis (Com Cautela)

Existem algumas situações onde variáveis globais podem ser usadas com menos risco, mesmo em programas concorrentes:

1.  **Constantes:** Variáveis globais declaradas como `const` são imutáveis e, portanto, seguras para serem lidas por múltiplas goroutines.
2.  **Configuração Imutável:** Variáveis globais que são inicializadas uma vez no início do programa (antes de qualquer goroutine acessá-las) e depois são tratadas como *read-only* (somente leitura) pelo resto da execução do programa. Exemplos incluem configurações carregadas de arquivos ou variáveis de ambiente. É crucial garantir que nenhuma goroutine tente modificá-las após a inicialização.

Mesmo nesses casos, é importante documentar claramente a natureza imutável ou *read-only* dessas variáveis.

### Conclusão

Variáveis globais podem parecer uma solução fácil para compartilhar estado entre diferentes partes de um programa, mas quando combinadas com a concorrência das goroutines em Go, elas se tornam uma fonte significativa de bugs complexos e difíceis de rastrear, principalmente devido a race conditions.

Para escrever código Go concorrente robusto, seguro e manutenível:

*   **Prefira passar dados explicitamente** como parâmetros para goroutines.
*   **Use canais** para comunicação e sincronização entre goroutines.
*   **Recorra a primitivas de sincronização** (`sync.Mutex`, `sync.RWMutex`, `sync.atomic`) com cautela quando o compartilhamento de memória for estritamente necessário, protegendo cuidadosamente o acesso aos dados compartilhados.
*   **Limite o uso de variáveis globais** a constantes verdadeiras ou configurações imutáveis inicializadas no início do programa.

Adotar essas práticas não apenas evitará as armadilhas das race conditions, mas também levará a um código mais claro, mais testável e mais fácil de entender e manter a longo prazo. Pense na segurança da concorrência desde o início do seu design em Go!

---


Descubra os perigos ocultos de usar variáveis globais em programas Go concorrentes que utilizam goroutines. Aprenda sobre race conditions e explore alternativas mais seguras e idiomáticas para gerenciar estado compartilhado.

Golang: Por que evitar variáveis globais com goroutines


# Introdução: O Mundo Flexível das Interfaces em Go

Go (ou Golang) é uma linguagem estaticamente tipada, o que significa que o tipo de uma variável é conhecido em tempo de compilação. No entanto, Go também oferece um poderoso mecanismo de flexibilidade através das **interfaces**. Uma interface define um conjunto de métodos que um tipo concreto *deve* implementar.

Variáveis do tipo interface podem armazenar qualquer valor concreto que satisfaça essa interface. Isso é fantástico para escrever código polimórfico e desacoplado. Mas e se você tiver uma variável de interface e precisar acessar o valor *concreto* original, com seus próprios métodos e campos específicos, que não fazem parte da interface? É aqui que entra a **Type Assertion**.

## O que é Type Assertion?

Type assertion em Go é um mecanismo que permite verificar o tipo concreto subjacente de um valor armazenado em uma variável de interface. É importante entender que Type Assertion só pode ser aplicada em variáveis de interface, não em variáveis de tipos concretos.

Essencialmente, você está dizendo ao compilador: "Eu acredito que o valor dentro desta interface é, na verdade, deste tipo específico. Por favor, me dê acesso a ele como tal".

A sintaxe básica é:

```go
valorConcreto := variavelInterface.(TipoConcreto)
```

Aqui, `variavelInterface` é a variável do tipo interface, e `TipoConcreto` é o tipo que você *espera* que esteja armazenado nela. Se a sua suposição estiver correta, `valorConcreto` receberá o valor com o tipo `TipoConcreto`.

**Mas atenção:** Se `variavelInterface` não contiver um valor do tipo `TipoConcreto`, essa operação causará um **panic**, encerrando o programa abruptamente. Por isso, existe uma forma mais segura.

### A Forma Segura: O "Comma, ok" Idiom

Para evitar panics indesejados, Go oferece uma forma mais segura e idiomática de fazer Type Assertion, que retorna dois valores:

```go
valorConcreto, ok := variavelInterface.(TipoConcreto)
```

Nesta forma:
1.  `valorConcreto`: Receberá o valor concreto (com o tipo `TipoConcreto`) se a asserção for bem-sucedida. Se falhar, receberá o valor zero do `TipoConcreto` (por exemplo, `0` para números, `""` para strings, `nil` para ponteiros, etc.).
2.  `ok`: Será um booleano `true` se a asserção for bem-sucedida (ou seja, `variavelInterface` realmente contém um `TipoConcreto`), e `false` caso contrário.

Usar o "comma, ok" idiom é a **maneira recomendada** de fazer Type Assertions, pois permite verificar se a operação foi bem-sucedida antes de usar o `valorConcreto`, evitando panics.

```go
if valorConcreto, ok := variavelInterface.(TipoConcreto); ok {
    // A asserção foi bem-sucedida!
    // Pode usar valorConcreto com segurança aqui, pois ele é do TipoConcreto.
    fmt.Println("Asserção bem-sucedida:", valorConcreto)
    // Chamar métodos específicos de TipoConcreto, acessar campos, etc.
} else {
    // A asserção falhou.
    // variavelInterface não contém um valor do TipoConcreto.
    // Lide com o erro ou siga um fluxo alternativo.
    fmt.Println("Asserção falhou. O tipo real não é TipoConcreto.")
}
```

### Por que Precisamos de Type Assertions? (Utilidade)

O principal motivo é **recuperar a especificidade perdida ao usar interfaces**. Quando você armazena um valor concreto (como um `*http.Request` ou um `MeuErroCustomizado`) em uma variável de interface (como `interface{}` ou `error`), você só pode acessar os métodos definidos pela interface.

Type Assertions são úteis quando:

1.  **Você precisa chamar métodos ou acessar campos específicos do tipo concreto** que não fazem parte da definição da interface.
2.  **Você precisa tratar diferentes tipos concretos de forma distinta**, mesmo que todos satisfaçam a mesma interface (por exemplo, diferentes tipos de erros que implementam a interface `error`).
3.  **Você está trabalhando com dados de fontes externas (JSON, APIs)** que podem ter tipos variados e precisam ser desembrulhados de `interface{}`.

### Analogias para Facilitar o Entendimento

Pense em Type Assertions como:

1.  **Abrir uma Caixa Misteriosa:** Uma variável de interface é como uma caixa fechada (`interface{}`). Você sabe que *algo* está dentro, mas não o quê exatamente. A Type Assertion (`caixa.(Brinquedo)`) é a tentativa de abrir a caixa *esperando* encontrar um `Brinquedo`. A forma segura (`brinquedo, ok := caixa.(Brinquedo)`) é como perguntar "Esta caixa contém um Brinquedo?" antes de abri-la. Se a resposta for sim (`ok == true`), você pega o `brinquedo`. Se não, você sabe que não deve tentar usá-lo como um brinquedo.

2.  **Identificar um Ator Fantasiado:** Imagine atores usando fantasias de animais (tipos concretos) que permitem que todos façam um som (método da interface `Animal`). Você tem um `Animal` (variável de interface) no palco. Você sabe que ele pode `FazerSom()`. Mas se você quiser que ele `AbaneOCauda()` (método específico do tipo `Cachorro`), você precisa primeiro verificar se o ator está *realmente* fantasiado de cachorro (`cachorro, ok := animal.(Cachorro)`). Se `ok` for `true`, você pode pedir para ele abanar a cauda com segurança.

### Exemplos do Mundo Real

#### Exemplo 1: Tratando Tipos Específicos de Erros

A interface `error` em Go é onipresente. Funções frequentemente retornam `error`. Às vezes, você quer verificar se o erro retornado é de um tipo específico para tratá-lo de forma diferente.

```go
package main

import (
	"fmt"
	"os"
)

// MeuErroCustomizado é um tipo específico de erro
type MeuErroCustomizado struct {
	Mensagem string
	Codigo   int
}

func (e *MeuErroCustomizado) Error() string {
	return fmt.Sprintf("Erro %d: %s", e.Codigo, e.Mensagem)
}

// FuncaoQuePodeFalhar simula uma operação que pode retornar diferentes erros
func FuncaoQuePodeFalhar(falharComErroCustomizado bool) error {
	if falharComErroCustomizado {
		return &MeuErroCustomizado{Mensagem: "Falha específica detectada", Codigo: 500}
	}
	// Simula outro tipo de erro, como um erro do pacote os
	_, err := os.Open("/arquivo/inexistente")
	return err
}

func main() {
	err1 := FuncaoQuePodeFalhar(true)
	err2 := FuncaoQuePodeFalhar(false)

	fmt.Println("Processando err1:")
	processarErro(err1)

	fmt.Println("\nProcessando err2:")
	processarErro(err2)
}

func processarErro(err error) {
	if err == nil {
		fmt.Println("Nenhum erro.")
		return
	}

	// Tentamos fazer a asserção para o nosso tipo de erro customizado
	if meuErro, ok := err.(*MeuErroCustomizado); ok {
		// Sucesso! É o nosso erro customizado.
		fmt.Printf("Erro customizado detectado! Código: %d, Mensagem: %s\n", meuErro.Codigo, meuErro.Mensagem)
		// Poderíamos ter lógica específica aqui baseada no Código, etc.
	} else if os.IsNotExist(err) {
		// Verificando outro tipo comum de erro usando funções auxiliares
		fmt.Println("Erro detectado: O arquivo ou diretório não existe.")
	} else {
		// É outro tipo de erro genérico
		fmt.Printf("Erro genérico detectado: %v\n", err)
	}
}
```

#### Exemplo 2: Trabalhando com Dados de JSON (map[string]interface{})

Ao decodificar JSON para uma estrutura genérica como `map[string]interface{}`, os valores podem ser strings, números (sempre `float64` em Go ao decodificar JSON), booleanos, outras maps, etc. Type Assertion é essencial para extrair e usar esses valores.

```go
package main

import (
	"encoding/json"
	"fmt"
	"log"
)

func main() {
	jsonString := `{"nome": "Alice", "idade": 30, "ativo": true, "metadata": {"cidade": "SP"}, "tags": null}`
	var dados map[string]interface{}

	err := json.Unmarshal([]byte(jsonString), &dados)
	if err != nil {
		log.Fatalf("Erro ao decodificar JSON: %v", err)
	}

	// Acessando o nome (esperamos uma string)
	if nome, ok := dados["nome"].(string); ok {
		fmt.Printf("Nome: %s (tipo: %T)\n", nome, nome)
	} else {
		fmt.Println("Chave 'nome' não encontrada ou não é uma string.")
	}

	// Acessando a idade (esperamos um número, JSON decodifica para float64)
	if idade, ok := dados["idade"].(float64); ok {
		// Podemos converter para int se necessário
		idadeInt := int(idade)
		fmt.Printf("Idade: %d (tipo original float64, convertido para %T)\n", idadeInt, idadeInt)
	} else {
		fmt.Println("Chave 'idade' não encontrada ou não é um número (float64).")
	}

	// Acessando um valor booleano
	if ativo, ok := dados["ativo"].(bool); ok {
		fmt.Printf("Ativo: %t (tipo: %T)\n", ativo, ativo)
	} else {
		fmt.Println("Chave 'ativo' não encontrada ou não é um booleano.")
	}

	// Acessando um objeto aninhado (esperamos map[string]interface{})
	if metadata, ok := dados["metadata"].(map[string]interface{}); ok {
		if cidade, ok := metadata["cidade"].(string); ok {
			fmt.Printf("Cidade (metadata): %s (tipo: %T)\n", cidade, cidade)
		} else {
			fmt.Println("Chave 'cidade' em metadata não encontrada ou não é string.")
		}
	} else {
		fmt.Println("Chave 'metadata' não encontrada ou não é um objeto (map).")
	}

	// Verificando valores null
	if _, ok := dados["tags"].(interface{}); ok && dados["tags"] == nil {
		fmt.Println("Tags está presente, mas é null")
	} else if _, ok := dados["tags"].([]interface{}); ok {
		fmt.Println("Tags é um array")
	} else {
		fmt.Println("Tags não encontrada ou tem um tipo diferente")
	}
}
```

### Cuidados e Boas Práticas

1.  **Prefira o "Comma, ok":** Sempre use a forma `valor, ok := i.(Tipo)` para evitar panics. A forma direta `valor := i.(Tipo)` só deve ser usada se você tem *certeza absoluta* (por lógica anterior no código) que a asserção terá sucesso, o que é raro e muitas vezes um sinal de design questionável.
2.  **Não Abuse:** Type assertions são úteis, mas seu uso excessivo pode ser um sinal de que seu design baseado em interfaces pode não ser o ideal ou que você está lutando contra o sistema de tipos. Tente projetar suas interfaces de forma que a necessidade de "desembrulhar" o tipo concreto seja minimizada.
3.  **Considere Type Switches:** Se você precisa verificar um valor de interface contra *vários* tipos concretos possíveis, um `type switch` é geralmente mais limpo e legível do que múltiplas `if/else if` com type assertions.

### Type Switch: Uma Alternativa Elegante para Múltiplas Verificações

Quando você tem uma variável de interface e quer executar lógicas diferentes dependendo do tipo concreto que ela armazena, o `type switch` é a ferramenta ideal.

```go
package main

import "fmt"

// Definição completa do MeuErroCustomizado
type MeuErroCustomizado struct {
	Codigo int
	Mensagem string
}

func (e *MeuErroCustomizado) Error() string {
	return fmt.Sprintf("Erro %d: %s", e.Codigo, e.Mensagem)
}

func processaQualquerCoisa(i interface{}) {
	switch v := i.(type) { // Note a sintaxe especial i.(type)
	case int:
		fmt.Printf("É um inteiro: %d\n", v)
		// v aqui tem o tipo int
	case string:
		fmt.Printf("É uma string: %s\n", v)
		// v aqui tem o tipo string
	case bool:
		fmt.Printf("É um booleano: %t\n", v)
		// v aqui tem o tipo bool
	case *MeuErroCustomizado:
		fmt.Printf("É nosso erro customizado! Código %d, Mensagem: %s\n", v.Codigo, v.Mensagem)
		// v aqui tem o tipo *MeuErroCustomizado
	case nil:
		fmt.Println("É um valor nil")
	default:
		fmt.Printf("Tipo desconhecido: %T, Valor: %v\n", v, v)
		// v aqui tem o mesmo tipo da interface original (i)
	}
}

func main() {
	processaQualquerCoisa(10)
	processaQualquerCoisa("Olá, Go!")
	processaQualquerCoisa(true)
	processaQualquerCoisa(&MeuErroCustomizado{Codigo: 404, Mensagem: "Página não encontrada"})
	processaQualquerCoisa(nil)
	processaQualquerCoisa(3.14) // Cairá no default
}
```

O `type switch` combina a verificação de tipo e a asserção em uma estrutura concisa e segura. Dentro de cada `case`, a variável `v` (ou qualquer nome que você der) já terá o tipo específico daquele case.

### Conclusão

Type Assertion é uma ferramenta fundamental no arsenal de um desenvolvedor Go para trabalhar eficazmente com a flexibilidade das interfaces. Ela permite "olhar por baixo do capô" de uma variável de interface e recuperar o tipo concreto original quando necessário.

Lembre-se sempre de usar a forma segura com o "comma, ok" idiom para evitar panics e de considerar `type switches` quando precisar lidar com múltiplos tipos possíveis. Compreender e usar Type Assertions corretamente permite escrever código Go mais robusto, flexível e capaz de lidar com uma variedade maior de situações do mundo real, especialmente ao interagir com sistemas externos ou ao construir arquiteturas extensíveis.

---


Aprenda o que é Type Assertion em Go (Golang), por que é útil para trabalhar com interfaces, como usar com segurança através do "comma ok idiom", e veja analogias e exemplos práticos do mundo real.

Type Assertion em Golang: Desvendando o poder das Interfaces


# Introdução: Além dos Hooks Básicos

![Dominando Hooks Avançados](/assets/img/dominando-hooks-avan-ados-usecallback-usememo-e-useref-em-cen-rios-reais-no-react.png)

Se você já trabalha com React há algum tempo, `useState` e `useEffect` provavelmente são seus companheiros diários. Eles formam a base da lógica de estado e ciclo de vida em componentes funcionais. No entanto, à medida que as aplicações crescem em complexidade, surgem desafios de performance, principalmente relacionados a re-renderizações desnecessárias.

É aqui que entram os Hooks "avançados": `useCallback`, `useMemo` e `useRef`. Eles não são necessariamente mais complexos de usar, mas seu propósito principal é a **otimização** e o gerenciamento de cenários específicos que os Hooks básicos não cobrem diretamente.

Neste artigo, vamos explorar cada um desses Hooks com exemplos práticos em TypeScript, focando em cenários reais onde eles brilham e ajudam a criar aplicações React mais eficientes e robustas.

## Entendendo a Re-renderização no React

Antes de mergulhar nos Hooks de otimização, é crucial entender por que um componente React re-renderiza:

1. **Mudança de Estado:** Quando o estado de um componente (gerenciado por `useState` ou `useReducer`) muda.
2. **Mudança de Props:** Quando as props recebidas de um componente pai são alteradas. **Importante:** React usa comparação por referência (`Object.is`) para objetos e funções. Isso significa que `{} !== {}` e `() => {} !== () => {}` (sempre `false`).
3. **Re-renderização do Pai:** Quando um componente pai re-renderiza, seus filhos também re-renderizam por padrão, a menos que otimizações sejam aplicadas (como `React.memo`).
4. **Context Update:** Quando um valor de contexto que o componente consome é alterado.

O problema surge quando re-renderizações ocorrem sem necessidade real, como passar uma nova instância de uma função (mesmo que com a mesma lógica) para um componente filho otimizado, ou recalcular valores complexos em cada renderização.

## useCallback: Memoizando Funções

**O que faz?** `useCallback` retorna uma versão *memoizada* da função callback que você passou. Essa função memoizada só muda se uma de suas dependências (listadas no array de dependências) for alterada.

**Por que usar?**
Principalmente para otimizar componentes filhos que dependem de callbacks passados como props. Se você passa uma função definida diretamente no corpo do componente pai para um filho envolvido em `React.memo`, o filho re-renderizará a cada renderização do pai, pois a função será uma nova instância a cada vez (falha na comparação por referência). `useCallback` garante que a mesma instância da função seja passada enquanto as dependências não mudarem.

**Cenário Real:** Passar um manipulador de eventos para um componente de item de lista memoizado.

```typescript
import React, { useState, useCallback } from 'react';

// Interface para as props do componente filho
interface ListItemProps {
  item: { id: number; text: string };
  onRemove: (id: number) => void; // Callback
}

// Componente filho memoizado para evitar re-renderizações desnecessárias
const ListItem = React.memo(({ item, onRemove }: ListItemProps) => {
  console.log(`Renderizando Item: ${item.id}`);
  return (
    <li>
      {item.text}
      <button onClick={() => onRemove(item.id)}>Remover</button>
    </li>
  );
});

// Componente Pai
const ListComponent: React.FC = () => {
  const [items, setItems] = useState([
    { id: 1, text: 'Item 1' },
    { id: 2, text: 'Item 2' },
  ]);
  const [newItemText, setNewItemText] = useState('');

  // SEM useCallback: Uma nova função `handleRemove` é criada em CADA renderização de ListComponent.
  // Isso faria com que TODOS os `ListItem` re-renderizassem quando algo no pai muda (ex: digitar no input).
  // const handleRemove = (id: number) => {
  //   setItems(prevItems => prevItems.filter(item => item.id !== id));
  // };

  // COM useCallback: A função `handleRemove` só é recriada se as dependências mudarem.
  // A mesma referência de função é passada para os `ListItem`, permitindo que `React.memo` funcione corretamente.
  const handleRemove = useCallback((id: number) => {
    setItems(prevItems => prevItems.filter(item => item.id !== id));
  }, []); // setItems é estável entre renderizações, então não precisa estar aqui

  const handleAdd = () => {
      if (!newItemText.trim()) return;
      const newItem = { id: Date.now(), text: newItemText };
      setItems(prevItems => [...prevItems, newItem]);
      setNewItemText('');
  }

  console.log("Renderizando ListComponent");

  return (
    <div>
      <input
        type="text"
        value={newItemText}
        onChange={(e) => setNewItemText(e.target.value)}
        placeholder="Novo item"
      />
      <button onClick={handleAdd}>Adicionar</button>
      <ul>
        {items.map(item => (
          <ListItem key={item.id} item={item} onRemove={handleRemove} />
        ))}
      </ul>
    </div>
  );
};

export default ListComponent;
```

**Observações importantes:**

1. As funções updater do `useState` (como `setItems(prevItems => ...)`) têm garantia de estabilidade pelo React, então não precisam ser listadas nas dependências
2. Se uma callback precisar acessar valores de estado ou props, esses valores precisam ser incluídos no array de dependências
3. Ideal para evitar renderizações em componentes memoizados e reduzir o trabalho do garbage collector

**Quando não usar:** Se a função não é passada como prop para um componente memoizado (`React.memo`), ou se não é usada como dependência em outros Hooks (como `useEffect`), o custo da memoização geralmente supera o benefício.

## useMemo: Memoizando Valores Computados

**O que faz?** `useMemo` retorna um valor *memoizado* resultante da execução da função que você passou. Ele recomputa o valor apenas quando uma das dependências (listadas no array de dependências) muda.

**Por que usar?**
Para evitar cálculos computacionalmente caros em cada renderização. Se um cálculo depende de props ou estado que não mudam frequentemente, `useMemo` pode armazenar o resultado e retorná-lo diretamente nas renderizações subsequentes, economizando tempo de processamento.

**Cenário Real:** Filtrar ou processar uma lista grande de dados que só deve ser recalculada quando os dados brutos ou os critérios de filtro mudarem.

```typescript
import React, { useState, useMemo } from 'react';

interface Product {
  id: number;
  name: string;
  category: string;
  price: number;
}

const initialProducts: Product[] = [
  // Imagine uma lista muito grande aqui (ex: 1000+ produtos)
  { id: 1, name: "Laptop Gamer", category: "Eletrônicos", price: 7500 },
  { id: 2, name: "Mouse Pad", category: "Acessórios", price: 80 },
  { id: 3, name: "Teclado Mecânico", category: "Eletrônicos", price: 450 },
  { id: 4, name: "Monitor Ultrawide", category: "Eletrônicos", price: 2200 },
  // ... mais produtos
];

// Função "cara" simulada (poderia ser um filtro complexo, ordenação, etc.)
const filterAndSortProducts = (products: Product[], categoryFilter: string): Product[] => {
  console.log(`--- Calculando Produtos Filtrados (Categoria: ${categoryFilter || 'Todas'}) ---`);

  // Em um caso real, este poderia ser um cálculo realmente intensivo
  const filtered = categoryFilter
    ? products.filter(p => p.category === categoryFilter)
    : products;

  return filtered.sort((a, b) => a.price - b.price); // Ordena por preço
};

const ProductList: React.FC = () => {
  const [products] = useState<Product[]>(initialProducts);
  const [selectedCategory, setSelectedCategory] = useState<string>('');
  const [theme, setTheme] = useState<'light' | 'dark'>('light'); // Estado irrelevante para a lista

  // SEM useMemo: filterAndSortProducts seria chamado em CADA renderização,
  // mesmo quando apenas `theme` muda, o que é desnecessário e custoso.
  // const visibleProducts = filterAndSortProducts(products, selectedCategory);

  // COM useMemo: filterAndSortProducts só é chamado quando `products` ou `selectedCategory` mudam.
  // Mudar o `theme` não causará o recálculo.
  const visibleProducts = useMemo(() => {
    return filterAndSortProducts(products, selectedCategory);
  }, [products, selectedCategory]);

  // Também podemos memoizar valores derivados mais simples
  const productCount = useMemo(() => {
    return visibleProducts.length;
  }, [visibleProducts]);

  console.log("Renderizando ProductList");

  return (
    <div style={{ background: theme === 'light' ? '#fff' : '#333', color: theme === 'light' ? '#000' : '#fff' }}>
      <h2>Lista de Produtos ({productCount})</h2>
      <button onClick={() => setTheme(t => t === 'light' ? 'dark' : 'light')}>
        Mudar Tema ({theme})
      </button>

      <div>
        <label>Filtrar por Categoria: </label>
        <select value={selectedCategory} onChange={(e) => setSelectedCategory(e.target.value)}>
          <option value="">Todas</option>
          <option value="Eletrônicos">Eletrônicos</option>
          <option value="Acessórios">Acessórios</option>
        </select>
      </div>

      <ul>
        {visibleProducts.map(product => (
          <li key={product.id}>
            {product.name} ({product.category}) - R$ {product.price.toFixed(2)}
          </li>
        ))}
      </ul>
    </div>
  );
};

export default ProductList;
```

**Casos de uso adicionais:**
1. Memoizar objetos passados como props para componentes filhos memoizados
2. Evitar recriação de objetos complexos que causam re-renderizações quando passados para outros componentes
3. Preparação de dados em formatação específica para gráficos ou visualizações

**Quando não usar:** Para cálculos simples e rápidos. A sobrecarga do `useMemo` pode ser maior que o benefício. Use apenas quando o cálculo for genuinamente caro ou quando a estabilidade referencial for necessária.

## useRef: Acessando o DOM e Mantendo Referências Mutáveis

**O que faz?** `useRef` retorna um objeto ref mutável cuja propriedade `.current` é inicializada com o argumento passado (initialValue). O objeto retornado persistirá durante todo o ciclo de vida do componente. **Importante:** Alterar a propriedade `.current` de um ref *não* causa uma nova renderização.

**Por que usar?**
1. **Acessar Elementos DOM:** Para interagir diretamente com nós do DOM (ex: focar um input, medir dimensões, integrar com bibliotecas não-React).
2. **Manter Valores Mutáveis:** Para armazenar um valor que precisa persistir entre renderizações, mas que não deve disparar uma nova renderização quando alterado (diferente do estado).

**Cenário Real 1:** Focar um campo de input automaticamente quando o componente monta.

```typescript
import React, { useRef, useEffect } from 'react';

const AutoFocusInput: React.FC = () => {
  // Cria uma ref. Inicialmente, inputRef.current é null.
  // Especificamos o tipo do elemento DOM que a ref irá referenciar.
  const inputRef = useRef<HTMLInputElement>(null);

  useEffect(() => {
    // Dentro do useEffect (que roda após a montagem do DOM),
    // inputRef.current apontará para o elemento <input>.
    // Usamos optional chaining (?.) por segurança, caso a ref não seja atribuída.
    inputRef.current?.focus();
  }, []); // Array de dependências vazio significa que roda apenas uma vez, após a montagem.

  return (
    <div>
      <label htmlFor="myInput">Input com Foco Automático: </label>
      {/* Associa a ref ao elemento input no DOM */}
      <input ref={inputRef} type="text" id="myInput" />
    </div>
  );
};

export default AutoFocusInput;
```

**Cenário Real 2:** Armazenar o valor anterior de uma prop ou estado.

```typescript
import React, { useState, useEffect, useRef } from 'react';

interface CounterProps {
    initialCount?: number;
}

const PreviousValueCounter: React.FC<CounterProps> = ({ initialCount = 0 }) => {
  const [count, setCount] = useState<number>(initialCount);
  // Ref para guardar o valor anterior de 'count'
  const prevCountRef = useRef<number | undefined>(undefined);

  useEffect(() => {
    // Este efeito roda *depois* da renderização.
    // Então, atualizamos a ref com o valor *atual* de 'count'
    // para que na *próxima* renderização, a ref contenha o valor anterior.
    prevCountRef.current = count;
  }, [count]); // Roda sempre que 'count' mudar

  // Durante a renderização, prevCountRef.current ainda contém o valor da renderização anterior.
  const prevCount = prevCountRef.current;

  return (
    <div>
      <p>Contador Atual: {count}</p>
      <p>Contador Anterior: {prevCount === undefined ? 'N/A' : prevCount}</p>
      <button onClick={() => setCount(c => c + 1)}>Incrementar</button>
    </div>
  );
};

export default PreviousValueCounter;
```

**Cenário Real 3:** Armazenar uma referência a um intervalo (setInterval) para limpá-lo depois.

```typescript
import React, { useState, useEffect, useRef } from 'react';

const Timer: React.FC = () => {
  const [seconds, setSeconds] = useState(0);
  // O tipo correto para timers no TypeScript é NodeJS.Timeout
  // ou usar number e depois aplicar cast quando necessário
  const intervalRef = useRef<NodeJS.Timeout | null>(null);

  useEffect(() => {
    // Inicia o timer
    intervalRef.current = setInterval(() => {
      setSeconds(s => s + 1);
    }, 1000);

    // Função de limpeza que será executada quando o componente desmontar
    return () => {
      if (intervalRef.current) {
        clearInterval(intervalRef.current);
      }
    };
  }, []); // Executa apenas na montagem

  const handleReset = () => {
    setSeconds(0);
  };

  return (
    <div>
      <p>Timer: {seconds} segundos</p>
      <button onClick={handleReset}>Resetar</button>
    </div>
  );
};

export default Timer;
```

**Quando não usar:** Para gerenciar dados que devem acionar uma atualização visual na tela quando mudam – para isso, use `useState` ou `useReducer`.

## Tipo Correto para useRef com TypeScript

Um erro comum em TypeScript é definir uma ref para um elemento DOM sem o tipo correto:

```typescript
// ❌ Incorreto - Não permite null inicialmente
const inputRef = useRef<HTMLInputElement>();

// ✅ Correto - O tipo inclui null para o valor inicial
const inputRef = useRef<HTMLInputElement | null>(null);
```

Ou quando criamos uma ref para armazenar um valor mutável:

```typescript
// ❌ Incorreto - Não especifica undefined
const prevValueRef = useRef<number>();

// ✅ Correto - Tipo correto com valor inicial
const prevValueRef = useRef<number | undefined>(undefined);
```

## Cuidado com a Otimização Prematura

Embora `useCallback`, `useMemo` e `useRef` sejam ferramentas poderosas, é fundamental não cair na armadilha da **otimização prematura**. React já é bastante rápido por padrão.

* **Não use `useCallback` e `useMemo` em todo lugar.** Eles têm um custo (criação da função/valor memoizado, comparação de dependências). Use-os apenas quando houver um gargalo de performance *real* e mensurável, geralmente identificado com ferramentas de profiling (React DevTools Profiler).
* **`React.memo` é frequentemente o pré-requisito:** `useCallback` e `useMemo` são mais eficazes quando usados em conjunto com componentes otimizados via `React.memo` ou quando as dependências de `useEffect` precisam ser estáveis.
* **Simplicidade primeiro:** Comece com o código mais simples e otimize apenas onde for necessário.

## Práticas Recomendadas e Padrões Comuns

### useCallback

1. **Evite dependências desnecessárias**
   ```typescript
   // ❌ Subótimo - inclui dependência desnecessária
   const handleSubmit = useCallback(() => {
     console.log('Submitting...');
     setSubmitting(true);
   }, [setSubmitting]); // setSubmitting é estável, não precisa estar aqui

   // ✅ Melhor - sem dependências desnecessárias
   const handleSubmit = useCallback(() => {
     console.log('Submitting...');
     setSubmitting(true);
   }, []);
   ```

2. **Use junto com React.memo para máxima eficiência**
   ```typescript
   // O componente filho só re-renderiza se suas props mudarem
   const ChildComponent = React.memo(({ onClick }) => {
     return <button onClick={onClick}>Click me</button>;
   });

   function ParentComponent() {
     // Esta função mantém a mesma referência entre renderizações
     const handleClick = useCallback(() => {
       console.log('Clicked!');
     }, []);

     return <ChildComponent onClick={handleClick} />;
   }
   ```

### useMemo

1. **Evite computações desnecessárias**
   ```typescript
   // ❌ Subótimo - executa filterExpensiveItems em cada renderização
   function ProductList({ products, threshold }) {
     const expensiveItems = products.filter(p => p.price > threshold);
     // ...
   }

   // ✅ Melhor - só recalcula quando products ou threshold mudam
   function ProductList({ products, threshold }) {
     const expensiveItems = useMemo(() => {
       return products.filter(p => p.price > threshold);
     }, [products, threshold]);
     // ...
   }
   ```

2. **Memoize objetos passados como props**
   ```typescript
   // ❌ Subótimo - cria um novo objeto em cada renderização
   function Parent() {
     const options = { sortBy: 'price', limit: 5 };
     return <Child options={options} />;
   }

   // ✅ Melhor - mantém a mesma referência se nada mudar
   function Parent() {
     const options = useMemo(() => {
       return { sortBy: 'price', limit: 5 };
     }, []);
     return <Child options={options} />;
   }
   ```

### useRef

1. **Armazenar valores sem causar re-renderizações**
   ```typescript
   function ScrollTracker() {
     // Guarda a posição de rolagem sem causar re-renderizações
     const lastScrollY = useRef(0);

     useEffect(() => {
       const handleScroll = () => {
         const currentScrollY = window.scrollY;
         if (Math.abs(currentScrollY - lastScrollY.current) > 50) {
           console.log('Rolagem significativa detectada');
           lastScrollY.current = currentScrollY;
         }
       };

       window.addEventListener('scroll', handleScroll);
       return () => window.removeEventListener('scroll', handleScroll);
     }, []);

     // ...
   }
   ```

2. **Integrações com bibliotecas de terceiros**
   ```typescript
   function ChartComponent({ data }) {
     const chartRef = useRef(null);
     const chartInstanceRef = useRef(null);

     useEffect(() => {
       if (chartRef.current) {
         // Criando uma instância da biblioteca de gráficos
         chartInstanceRef.current = new ChartLibrary(chartRef.current);
         chartInstanceRef.current.render(data);
       }

       // Limpeza quando o componente desmontar
       return () => {
         if (chartInstanceRef.current) {
           chartInstanceRef.current.destroy();
         }
       };
     }, [data]);

     return <div ref={chartRef} />;
   }
   ```

## Conclusão

Dominar `useCallback`, `useMemo` e `useRef` eleva suas habilidades em React, permitindo criar aplicações mais performáticas e lidar com cenários complexos de forma elegante.

* **`useCallback`** é seu aliado para estabilizar referências de funções, crucial para otimizar componentes filhos memoizados e dependências de `useEffect`.
* **`useMemo`** brilha ao evitar recálculos caros, garantindo que operações pesadas só ocorram quando suas dependências realmente mudarem.
* **`useRef`** oferece uma ponte para o DOM e uma maneira de manter valores mutáveis que não disparam re-renderizações.

Lembre-se de usá-los com propósito, focando em resolver problemas reais de performance ou necessidade de referências estáveis, e sempre meça o impacto de suas otimizações. Com prática e compreensão, esses Hooks se tornarão ferramentas valiosas no seu arsenal de desenvolvimento React.

---


Vá além do useState e useEffect! Aprenda a otimizar suas aplicações React com exemplos práticos de useCallback, useMemo e useRef em TypeScript, entendendo quando e por que usá-los para evitar re-renderizações desnecessárias e gerenciar referências.

Dominando Hooks Avançados: useCallback, useMemo e useRef em Cenários Reais no React


# Introdução ao Event Loop

![Entendendo profundamente o event loop e como ele afeta seu código](/assets/img/entendendo-profundamente-o-event-loop-e-como-ele-afeta-seu-codigo.png)

O event loop é uma das características mais poderosas e ao mesmo tempo complexas do JavaScript e do Node.js. Ele possibilita a execução de código assíncrono, ou seja, tarefas que não bloqueiam a execução do programa enquanto aguardam por alguma resposta. Esse comportamento é fundamental para aplicações com alto grau de concorrência e interatividade.

Para entendermos melhor o event loop, é importante conhecer sua arquitetura básica. É importante notar que o event loop tem implementações diferentes no navegador e no Node.js, embora o conceito fundamental seja o mesmo. Vamos analisar os componentes essenciais:

1. **Thread**: A thread é a unidade fundamental de execução do programa. Tanto no Node.js quanto nos navegadores, existe apenas uma única thread principal que executa todo o código JavaScript.

2. **Call Stack**: A pilha de chamadas armazena todas as funções que estão sendo executadas no momento. Quando uma função é chamada, ela é empilhada na call stack; quando ela termina, é desempilhada.

3. **Callback Queues**: Existem diferentes filas de callbacks para diferentes tipos de eventos assíncronos. Estas filas têm prioridades diferentes e são processadas em momentos específicos pelo event loop.

4. **Event Loop**: O event loop é o mecanismo que constantemente monitora a call stack e as filas de callback, movendo funções das filas para a call stack quando esta está vazia.

## Navegador vs Node.js: Implementações Diferentes

É crucial entender que o event loop tem implementações diferentes nos navegadores e no Node.js:

**Navegadores**:
- Utilizam Web APIs (como setTimeout, fetch, DOM events)
- As tarefas assíncronas são gerenciadas por estas APIs e depois enviadas para a Task Queue
- Possui uma implementação mais simples com Task Queue e Microtask Queue

**Node.js**:
- Utiliza a biblioteca libuv para implementar o event loop
- Possui fases específicas para gerenciar diferentes tipos de eventos
- Oferece APIs adicionais como `process.nextTick()` e `setImmediate()`

## Como o Event Loop funciona

Para ilustrar melhor como o event loop funciona, podemos analisar um exemplo simples em JavaScript:

```javascript
console.log('Início');

setTimeout(() => {
  console.log('Timeout');
}, 0);

console.log('Fim');
```

Quando executamos o programa, a saída será:

```
Início
Fim
Timeout
```

Isso acontece porque o `setTimeout`, mesmo com delay 0, envia o callback para a fila de tarefas, que só será executado depois que o código síncrono for concluído.

### Entendendo as Microtasks

Um conceito crucial frequentemente negligenciado é o de microtasks. As microtasks (como Promises) têm prioridade sobre as tarefas regulares (como setTimeout) e são executadas imediatamente após o código síncrono, antes do próximo ciclo do event loop:

```javascript
console.log('Início');

setTimeout(() => {
  console.log('Timeout');
}, 0);

Promise.resolve().then(() => {
  console.log('Promise');
});

console.log('Fim');
```

A saída deste código será:

```
Início
Fim
Promise
Timeout
```

Observe como a Promise é executada antes do setTimeout, mesmo que o setTimeout tenha sido chamado primeiro. Isso demonstra a ordem de prioridade:

1. Código síncrono (call stack)
2. Microtasks (Promises, queueMicrotask, process.nextTick no Node.js)
3. Tasks regulares (setTimeout, setInterval, I/O, etc.)

### Fases do Event Loop no Node.js

O event loop do Node.js possui as seguintes fases principais, que são executadas em ordem sequencial:

1. **Timers**: Executa callbacks agendados por `setTimeout` e `setInterval`.
2. **Pending callbacks**: Executa callbacks de operações de I/O que foram adiados para a próxima iteração do loop.
3. **Poll**: Verifica se há novos eventos de I/O e executa seus callbacks. Pode bloquear temporariamente aguardando novos eventos.
4. **Check**: Executa callbacks agendados por `setImmediate()`.
5. **Close callbacks**: Executa callbacks de eventos de fechamento, como `socket.on('close', ...)`.

Além dessas fases, o Node.js tem duas filas especiais:
- `process.nextTick()`: Executa callbacks imediatamente após a operação atual, antes de qualquer outra fase do event loop
- Microtasks de Promises: Executadas após `process.nextTick()` e antes da próxima fase do event loop

## Impacto no seu código

Agora que entendemos melhor como o event loop funciona, podemos analisar alguns casos de uso mais complexos e ver como ele afeta nosso código. Vamos considerar um exemplo em Node.js com uma função assíncrona que depende do resultado de outra:

```javascript
const fs = require('fs');

function readFileAsync(filename) {
  return new Promise((resolve, reject) => {
    fs.readFile(filename, 'utf8', (err, data) => {
      if (err) {
        reject(err);
      } else {
        resolve(data);
      }
    });
  });
}

async function processFiles() {
  try {
    const file1 = await readFileAsync('file1.txt');
    const file2 = await readFileAsync('file2.txt');
    console.log(file1, file2);
  } catch (err) {
    console.error(err);
  }
}

processFiles();
```

Neste código, chamamos a função `readFileAsync` duas vezes dentro da função `processFiles`. Como essa função é assíncrona, ela não bloqueia a execução do programa enquanto espera pelo resultado da leitura dos arquivos. O event loop gerencia essas operações de I/O através da fase "Poll" e, quando cada leitura é concluída, o respectivo callback é executado.

É importante notar que, com o uso de `async/await`, o segundo arquivo só começará a ser lido depois que o primeiro estiver completo. Isso ocorre porque `await` pausa a execução da função assíncrona até que a Promise seja resolvida.

## Dicas práticas para trabalhar com o Event Loop

1. **Evite bloquear o event loop**: Operações síncronas pesadas podem bloquear a thread principal e impedir o processamento de outras tarefas.

2. **Use microtasks para tarefas de alta prioridade**: Quando precisar que algo seja executado o mais rápido possível após o código atual, use Promises ou `queueMicrotask()`.

3. **Entenda a ordem de execução**: Código síncrono → Microtasks → Tasks regulares.

4. **No Node.js, use `process.nextTick()` com moderação**: Embora seja a forma mais rápida de agendar um callback, o uso excessivo pode prejudicar o event loop, impedindo que outras fases sejam executadas.
5. **Conheça as diferenças entre ambientes**: O comportamento do event loop pode variar entre navegadores e versões do Node.js.

## Conclusão

O event loop é um conceito fundamental para entender como o JavaScript e o Node.js lidam com a execução assíncrona de código. Compreender suas particularidades pode nos ajudar a escrever aplicações mais eficientes e escaláveis, bem como debugar problemas relacionados à concorrência e ao gerenciamento de tarefas assíncronas.

Lembre-se sempre de que o event loop é uma ferramenta poderosa, mas também complexa. Para usá-lo com eficiência, é preciso ter uma boa noção de como ele funciona internamente e como isso afeta nosso código. Com prática e experiência, você poderá se tornar um mestre do event loop e dominar a arte da programação assíncrona em JavaScript e Node.js.

Até a próxima!


Neste post, exploraremos detalhadamente o event loop do Node.js, sua relação com a execução assíncrona de código e como entender suas particularidades pode tornar você um desenvolvedor mais eficiente.

Entendendo profundamente o event loop e como ele afeta seu código


# Introdução
Os closures são um dos conceitos mais poderosos e avançados da linguagem JavaScript. Eles permitem que uma função tenha acesso a variáveis externas à sua própria escopo, mesmo depois de terem sido executadas.
![Closures](/assets/img/entendendo-closures-em-javascript.png)

## O que são Closures?
Em termos simples, um closure é uma função que tem acesso a uma variável externa à sua própria escopo, mesmo após a execução da função externa ter terminado. Isso significa que as variáveis externas à função não são destruídas após a execução da função, mas mantidas em memória enquanto houver alguma referência a elas.

### Como funcionam os Closures?
Para entender como os closures funcionam, precisamos primeiro entender o conceito de escopo em JavaScript. Em JavaScript, o escopo é determinado pela posição de uma variável no código e pelo contexto em que ela é acessada.

Uma função interna (ou filha) tem acesso às variáveis da função externa (ou mãe) devido ao conceito de "encapsulamento" ou "fechamento" do escopo. Quando uma função interna é executada, seu escopo é fechado, ou seja, ele mantém referência às variáveis externas mesmo após a execução da função externa ter terminado.

A seguir, temos um exemplo prático em JavaScript:

```javascript
function counter() {
  let count = 0;

  function increment() {
    count++;
    console.log(count);
  }

  return increment;
}

const incrementCounter = counter();
incrementCounter(); // Output: 1
incrementCounter(); // Output: 2
```

No exemplo acima, a função `counter` retorna outra função chamada `increment`. Quando chamamos `counter()`, estamos criando uma nova instância da função `increment` com seu próprio escopo fechado, mantendo a variável `count` em memória. Dessa forma, cada vez que chamamos `incrementCounter()`, o valor de `count` é incrementado e exibido no console.

### Uso prático dos Closures
Os closures são extremamente úteis em situações onde precisamos criar funções com estado próprio, ou seja, funções que mantêm seu próprio contexto interno sem depender do escopo global. Eles também são utilizados em casos de currying, onde uma função recebe um número variável de argumentos e retorna outra função com os parâmetros parciais já definidos.

Um exemplo de uso prático dos closures é a criação de funções de alto nível que precisam ter acesso às variáveis do escopo externo, como no caso de iteradores ou loopings:

```javascript
function makeIterator(array) {
  let index = 0;

  return {
    next: function() {
      if (index >= array.length) {
        return null;
      }
      const result = array[index];
      index++;
      return { value: result, done: false };
    }
  };
}

const it = makeIterator([1, 2, 3]);
console.log(it.next()); // Output: { value: 1, done: false }
console.log(it.next()); // Output: { value: 2, done: false }
console.log(it.next()); // Output: { value: 3, done: false }
console.log(it.next()); // Output: null
```

No exemplo acima, a função `makeIterator` recebe um array como parâmetro e retorna um objeto com um método chamado `next`. O método `next` tem acesso à variável externa `index`, que é incrementada a cada chamada. Dessa forma, podemos iterar sobre o array sem precisar de uma estrutura de loop explícita.

### Conclusão
Os closures são um conceito fundamental em JavaScript e uma ferramenta poderosa para desenvolvedores que buscam criar código mais modular, reutilizável e eficiente. Compreender como eles funcionam pode nos ajudar a escrever código mais limpo, seguro e performático.


Neste artigo, exploraremos o conceito de closures em JavaScript, sua importância e como eles podem ser úteis no desenvolvimento de aplicações web modernas.

Entendendo Closures em JavaScript

# Desbravando a Concorrência em Go: Uma Jornada Pelo Mundo das Goroutines e Canais

A linguagem de programação Go (Golang) é conhecida por sua poderosa capacidade de concorrência, proporcionada pelas goroutines e canais. Neste artigo, exploraremos como aproveitar ao máximo esses recursos para criar código eficiente, escalável e concorrente em Go. Veremos exemplos práticos de situações em que a concorrência se destaca, demonstrando como as goroutines e os canais podem ser fundamentais para resolver problemas complexos.

## Entendendo Goroutines

As goroutines são threads leves que são gerenciadas pelo próprio Go runtime. Elas permitem a execução concorrente de funções de forma eficiente, sem a sobrecarga de threads tradicionais. A criação de goroutines é simples, basta adicionar a palavra-chave `go` antes da chamada de uma função:

```go
package main

import (
	"fmt"
	"time"
)

func main() {
	go minhaRotinaConcorrente() // Inicia uma goroutine
	time.Sleep(time.Second)     // Aguarda um segundo para permitir a execução da goroutine
}

func minhaRotinaConcorrente() {
	fmt.Println("Executando em uma goroutine!")
}
```

## Benefícios da Concorrência com Goroutines

### 1. Execução Assíncrona

Imagine um servidor que precisa atender várias requisições simultaneamente. Utilizando goroutines, podemos lidar com cada requisição de forma assíncrona, mantendo a capacidade de resposta do servidor mesmo sob carga pesada.

```go
package main

import (
	"fmt"
	"net/http"
)

func main() {
	http.HandleFunc("/", handleRequest)
	http.ListenAndServe(":8080", nil)
}

func handleRequest(w http.ResponseWriter, r *http.Request) {
	go processarRequisicaoAssincrona(r)
	fmt.Fprint(w, "Requisição recebida com sucesso!")
}

func processarRequisicaoAssincrona(r *http.Request) {
	// Lógica de processamento pesado aqui
	fmt.Println("Processando requisição assincronamente:", r.URL.Path)
}
```

### 2. Paralelismo Simples

Com goroutines, o paralelismo torna-se acessível e fácil de implementar. O exemplo a seguir realiza a busca simultânea em várias fontes de dados:

```go
package main

import (
	"fmt"
	"sync"
)

func main() {
	var wg sync.WaitGroup
	frases := []string{"goroutines são incríveis", "canais simplificam a concorrência"}

	for _, frase := range frases {
		wg.Add(1)
		go func(f string) {
			defer wg.Done()
			processarFrase(f)
		}(frase)
	}

	wg.Wait()
}

func processarFrase(frase string) {
	// Lógica de processamento da frase aqui
	fmt.Println("Processando frase:", frase)
}
```

## Utilizando Canais para Comunicação Concorrente

Os canais em Go são meios de comunicação entre goroutines. Eles facilitam a troca de dados de forma segura e sincronizada. Vamos explorar um exemplo de como os canais podem ser úteis para coordenar a execução concorrente.

```go
package main

import (
	"fmt"
	"time"
)

func main() {
	ch := make(chan string)

	go enviarMensagem(ch)
	mensagem := <-ch

	fmt.Println("Mensagem recebida:", mensagem)
}

func enviarMensagem(ch chan string) {
	time.Sleep(time.Second)
	ch <- "Olá, estou na goroutine!"
}
```

## Conclusão

As goroutines e os canais são recursos poderosos em Go, proporcionando uma maneira eficiente e simples de trabalhar com concorrência. Ao integrá-los em seus projetos, você pode melhorar a eficiência, a escalabilidade e a capacidade de resposta do seu código. Este artigo apresentou conceitos básicos e exemplos práticos para inspirar o uso efetivo desses recursos em suas próprias aplicações em Go. Se surgirem dúvidas ou se você quiser compartilhar suas experiências, sinta-se à vontade para utilizar a seção de comentários abaixo.

Descubra como as goroutines e canais em Golang revolucionam a concorrência em desenvolvimento de software. Aprenda a criar código eficiente e escalável, explorando exemplos práticos que destacam os benefícios da programação concorrente em Go. Uma jornada emocionante pelo poder das goroutines e canais que transformará a maneira como você aborda a execução simultânea de tarefas em seus projetos.

Uso Efetivo de Goroutines e Canais em Golang

# Extracting Essential Data from APIs with Go Structs

The data universe is vast, especially when we're dealing with APIs that return huge amounts of information. Often, most of these data may be irrelevant to the task we're performing, making data sifting a tiresome task. However, with the Go programming language, we can simplify this process using a feature called struct.

In today's post, we'll explore how structs in Go can be used to extract only the data we need from an API response. For this, we'll be using the GitHub API as our example.

## Understanding Structs in Go

In Go, a struct is a composite data type that allows you to group zero or more values of other data types. It's like a custom blueprint that can be filled with the desired data. Each value in a struct is referred to as a field. You define a struct and then create instances of it, which you can manipulate as desired.

Here is an example of a simple struct in Go:

```go
type Person struct {
    Name    string
    Age     int
    Address string
}
```

## Using Structs to Decode API Responses

Now, let's think about a situation where we're making a call to the GitHub API and we receive a JSON response. However, we're only interested in some specific information - for instance, the name and slug of a repository.

To do this, we can create a struct that has only the fields we need:

```go
type Repository struct {
	Name string `json:"name"`
	Slug string `json:"slug"`
}
```

Let's make the API call and get the response:

```go
resp, err := http.Get("https://api.github.com/repos/openai/gpt-3")
if err != nil {
	log.Fatalln(err)
}

body, err := ioutil.ReadAll(resp.Body)
if err != nil {
	log.Fatalln(err)
}
```

And then we can unmarshal the JSON into our struct:

```go
var repo Repository
err = json.Unmarshal(body, &repo)
if err != nil {
	log.Fatalln(err)
}

fmt.Println(repo.Name, repo.Slug)
```

Go will automatically fill the `Name` and `Slug` fields with the corresponding data from the JSON and ignore the rest.

This is a powerful time and effort saver, especially when dealing with APIs that return large amounts of data. With the use of structs, we can focus only on the data that really matters to our programming needs.

## Conclusion

The Go programming language provides robust and effective tools for handling data, making it easier for developers to focus on what really matters. In this post, we explored the power of structs and how they can be used to extract specific information from complex API responses.


Explore the power of Go Structs in simplifying data extraction from APIs. This blog post showcases a hands-on approach to using Go Structs for decoding API responses, focusing only on essential data, using the GitHub API as an example. It is a practical guide for developers aiming to streamline their data management process in Go.

Extracting Essential Data from APIs with Go Structs

# Como configurar seu próprio HomeLab: Um Guia Passo a Passo para Instalar o Proxmox

## Introdução

No mundo da tecnologia, a aprendizagem prática é inestimável. **Uma das melhores maneiras de adquirir essa experiência é através da configuração de um HomeLab**. Mas o que é um HomeLab? E por que você deveria considerar ter um? Vamos mergulhar nisso.

## O que é um HomeLab?

Um HomeLab é, em essência, um laboratório de TI pessoal que você configura em casa. **Ele permite que você experimente e aprenda sobre servidores, redes, sistemas operacionais e aplicações em um ambiente seguro e controlado.** 

## Por que ter um HomeLab?

Existem várias razões pelas quais ter um HomeLab pode ser benéfico:

1. **Aprendizado**: Um HomeLab oferece um ambiente seguro para aprender e experimentar novas tecnologias sem o risco de prejudicar um sistema em produção.
2. **Desenvolvimento de habilidades**: Com um HomeLab, você pode aprimorar suas habilidades em áreas como administração de sistemas, redes, segurança cibernética e muito mais.
3. **Teste de software**: Você pode usar seu HomeLab para testar novos softwares ou atualizações antes de implementá-los em um ambiente de produção.
4. **Diversão**: Sim, acredite ou não, a configuração e a manutenção de um HomeLab podem ser bastante divertidas se você é apaixonado por tecnologia!

## Como começar com um HomeLab?

Para começar com um HomeLab, você precisará de alguns componentes essenciais:

1. **Hardware**: Isso **pode ser um PC, notebook ou até mesmo um Raspberry Pi**. O hardware que você escolhe depende do que você planeja fazer com seu HomeLab. Para um servidor de mídia ou um pequeno servidor de arquivos, um Raspberry Pi pode ser suficiente. Para tarefas mais pesadas, como hospedar máquinas virtuais, você pode precisar de um PC ou notebook mais robusto.
2. **Sistema Operacional**: Existem muitos sistemas operacionais que você pode usar em seu HomeLab, incluindo Windows, Linux e BSD. A escolha do sistema operacional depende de suas necessidades e preferências pessoais.
3. **Software de virtualização**: Um software de virtualização permite que você execute várias máquinas virtuais em um único servidor físico. Isso é útil para experimentar diferentes sistemas operacionais ou configurações de software sem a necessidade de hardware adicional.

## Instalando o Proxmox em seu HomeLab

Um dos softwares de virtualização mais populares para HomeLabs é o Proxmox. Aqui está um guia passo a passo sobre como instalar o Proxmox em seu HomeLab:

1. **Baixe a ISO do Proxmox**: Você pode baixar a ISO mais recente do Proxmox do [site oficial](https://www.proxmox.com/en/downloads).
2. **Crie um dispositivo de inicialização**: Use um programa como o Rufus para criar um dispositivo de inicialização USB com a ISO do Proxmox.
3. **Instale o Proxmox**: Inicie seu servidor a partir do dispositivo USB e siga as instruções na tela para instalar o Proxmox, o passo a passo é bem tranquilo e durante a instalação possui algumas dicas, mas caso precise de alguma ajuda a mais, deixe nos comentários que vou te ajudar.
4. **Configure o Proxmox**: Depois de instalado, você pode acessar a interface web do Proxmox para configurar seu servidor, que será no ip local do seu servidos com a porta `8006`.

## Conclusão

Ter um HomeLab é uma excelente maneira de aprender sobre tecnologia e aprimorar suas habilidades. Com o hardware certo e o software de virtualização Proxmox, você pode criar um ambiente de aprendizado poderoso e flexível em sua própria casa. Então, por que não começar a construir seu HomeLab hoje?

## Próximos Passos

Este artigo é apenas o começo de uma série que planejo sobre HomeLabs. Oobjetivo é ajudá-lo a aproveitar ao máximo seu laboratório doméstico, fornecendo informações detalhadas e orientações passo a passo sobre várias tecnologias e práticas. 

No próximo artigo, vamos mergulhar mais fundo no Proxmox. Vamos explorar suas características e funcionalidades, e mostrar como você pode usá-lo para subir serviços em seu HomeLab. Se você está interessado em transformar seu HomeLab em uma poderosa ferramenta de aprendizado e experimentação, não perca nossos próximos artigos.

Certifique-se de continuar acompanhando nossa série de HomeLab para obter mais dicas, truques e tutoriais detalhados. Até a próxima!

Como configurar seu próprio HomeLab: Um Guia Passo a Passo para Instalar o Proxmox.

Como montei meu homelab - Parte 1: Sistema Operacional

## Introdução

![Logo do Eslint](/assets/img/1_3adbbrn3gotbz72xqfo96g.png)

> [ESLint](https://eslint.org/) é um projeto open source que ajuda a encontrar e corrigir problemas em seu código JavaScript. Não importa se está escrevendo código no navegador ou no servidor, com ou sem framework, o ESLint pode ajudar seu código a ser mais consistente e robusto.

*Trecho retirado da documentação do ESLint.*

---

Além de checarmos problemas, podemos forçar um padrão e regras no código. O que queremos que seja um erro, aviso, verificado ou ignorado.

### Naming Convention

Com typescript-eslint, conseguimos definir um prefixo para variáveis com tipos **booleans**.\
Seguindo essa convenção, uma variável booleana "open" daria erro no código, e precisaríamos alterá-la para `isOpen` ou algo do tipo!

```json
// .eslintrc.json

{
  ...
  "rules": {
    ...
    "@typescript-eslint/naming-convention": [
      "error",
      {
        "selector": "variable",
        "types": ["boolean"],
        "format": ["PascalCase"],
        "prefix": ["is", "should", "has", "can", "did", "will"]
      }
    ]
  }
}
```

### I﻿mport Order

C﻿om Import Order conseguimos, como nome induz, organizar a ordem de nossos imports.

N﻿o exemplo abaixo, sempre o que vem do react ficaria no topo, logo após nossos components, templates, types e etc... Podemos definir se queremos um espaço em branco entre cada um ou não. E o melhor, isso tudo será sempre arrumado ao salvar o arquivo! Então não precisamos nos preocupar em arrumar e sempre teremos um arquivo padronizado!

```json
// .eslintrc.json
"import/order": [
      "error",
      {
        "newlines-between": "always",
        "pathGroups": [
          {
            "pattern": "react",
            "group": "builtin",
            "position": "before"
          },
          {
            "pattern": "components/**",
            "group": "external",
            "position": "after"
          },
          {
            "pattern": "templates/**",
            "group": "external",
            "position": "after"
          },
          {
            "pattern": "types/**",
            "group": "external",
            "position": "after"
          },
          {
            "pattern": "utils/**",
            "group": "external",
            "position": "after"
          }
        ],
        "pathGroupsExcludedImportTypes": ["builtin"],
        "groups": [
          "builtin",
          "external",
          "internal",
          "parent",
          "sibling",
          "index",
          "object"
        ],
        "alphabetize": {
          "order": "asc"
        }
      }
    ],
```

### D﻿efault Export

C﻿om essa regra, definimos que todos os export serão named exports e não default, assim utilizando o nome dado e garantindo também que teremos nomes únicos na aplicação, e o próprio arquivo que define o nome dele, e não quem importa, ficando mais fácil também, que o refactor funcione até melhor!

```json
"import/prefer-default-export": "off",
"import/no-default-export": "error",
```

## C﻿onclusão

E﻿ssas são algumas regras que gosto de utilizar em meus projetos para manter um padrão melhor, visto que cada pessoa costuma organizar os imports de uma forma, ou as vezes não dá um nome tão claro a uma variável, com isso, fica mais fácil encontrar as coisas e até mesmo gerar um código limpo!

E﻿m breve trarei uma segunda parte desse artigo, e também não deixe de me contatar no LinkedIN ou Twitter, caso tenha alguma dúvida ou recomendação!


ESLint ajuda a mantermos um padrão no código e verificar erros. Aqui estarei listando algumas regras que não vivo sem!

O poder do ESLint - Regras que mais gosto de usar


## Introdução

![Imagem representando sinais de acessibilidade](/assets/img/acessibilidade-parte-2.jpeg)

Antes de mais nada, se você ainda não leu a parte 1 deste tema, recomendo que leia-o, basta [clicar aqui](/como-melhorar-acessibilidade).

A ideia de uma continuação veio a partir do [Episódio 3 do reality](https://youtu.be/Ccyegys681I?t=300) Show me the code, feito pela [Rocketseat](https://www.rocketseat.com.br/).
Onde no terceiro episódio o foco era aumentar e melhorar a acessibilidade do site em questão.

Então, com isso, separei mais alguns pontos do que fazer e como testar a acessibilidade.

### TabIndex

O tabIndex nada mais é do que uma propriedade que inserimos em elementos da tela para definir uma ordem de navegação pelo teclado.

Como neste exemplo retirado do MDN:

```html
<p>Clique em qualquer lugar deste painel, então tente navegar pelos elementos utilizando tab</p>

<label>O primeiro na ordem do tab<input type="text"></label>

<div tabindex="0">Pode ser acessado via tab por conta do tabindex</div>

<div>Não "tabeável" por não possuir tabindex</div>

<label>Terceiro na ordem do tab<input type="text"></label>
```

O resultado, assim como mais explicações pode ser acessado na [documentação do MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex).

### Contrastes de cor

Muitas pessoas tem dificuldades de percepção de cor, assim como o alto contraste pode dificultar/machucar a visão.
Um exemplo bem básico disso é colocar um amarelo `#f5ff6f` nos textos enquanto o fundo está branco, por exemplo. Você terá de fazer um esforço enorme para conseguir ler o texto. E isso pode vir e virá a incomodar bastante sua visão com o tempo.
Para isso existe a WCAG, que trás diretrizes que podemos seguir, a fim de obtermos uma boa acessibilidade!

Existem sites que te ajudam a validar se o background e a cor do texto possuem um nível de contraste bom, como o [Color A11y](https://color.a11y.com/?wc3). O ideal seria conseguir o máximo de aprovação neste teste, para garantir que todos consigam ler da melhor forma.

O próprio DevTools ajuda com isso, como no exemplo a seguir:

![Imagem onde mostro a visualização do devTools, na forma como ele ajuda com o contraste e acessibilidade exibindo curvas no seletor de cor.](/assets/img/devTools-contraste.png)

### Conclusão

Então é isso, conseguimos dar uma passada bem rápida e legal sobre o tema, e se o post te ajudou de alguma forma compartilhe e comente se já sabia de alguma dessas informações e quem sabe eu faça mais alguns posts sobre acessibilidade. Podemos até aprofundar em algum dos temas citados neste post!

Obrigado por ler!


Como melhorar a acessibilidade de seus sites - Parte 2


## Introdução

![Imagem representando sinais de acessibilidade](/assets/img/acessibilidade-medium.png)

Acessibilidade é um tópico muito falado mas muitas vezes vejo isso sendo deixado de lado.

Por ser um tópico bem grande, hoje irei abordar alguns pontos que são fáceis de começar e bem fácil de lembrar durante seu desenvolvimento.

### Outline

Já notou que nos navegadores baseados no Chromium e no Firefox algumas interações possuem um comportamento padrão do navegador?
Como por exemplo a seleção de um botão ou input. Como nos exemplos abaixo:

![Imagem onde mostra exemplos de foco de botões no Chrome, Safari e Firefox.](/assets/img/outline-chrome.png)

Muitas vezes eu vejo sites onde removem por completo o outline em CSS Reset. E isso implica diretamente na acessibilidade.

Pessoas que utilizam navegação pelo teclado ou não conseguem identificar alterações de cores não conseguem detectar o que está acontecendo caso essa propriedade seja removida. Okay, entendo que talvez não combine muito com o layout, mas **não o remova**, você pode alterar o comportamento padrão do navegador e aplicar seu próprio estilo.

Basta seguir este artigo para ter uma ideia melhor: [Copy the Browser’s Native Focus Styles](https://css-tricks.com/copy-the-browsers-native-focus-styles/)

### Textos alternativos

Textos alternativos são super importantes!

Seja pra SEO, acessibilidade e até performance.
O texto alternativo, ou `alt`, de uma imagem, por exemplo, quando a imagem não carregar o texto será exibido de placeholder. E além disso, os leitores de tela farão uso deste texto, então lembre-se de fazer um texto que faça sentido e que ajude quem realmente precisa. **Tente descrever o máximo a imagem!**

### ESLint

ESLint é o seu melhor amigo durante o desenvolvimento. Além de te ajudar a manter um bom código ele pode te ajudar com acessibilidade também!

[**eslint-plugin-jsx-a11y**](https://www.npmjs.com/package/eslint-plugin-jsx-a11y)

Esse plugin vai te ajudar com vários pontos importantes de acessibilidade, como garantir os textos alternativos, a inclusão de `aria` em seus componentes, verificar se as anchor tags são válidas, se os emojis estão corretos e possuem acesso aos leitores de tela entre inúmeras funcionalidades. Vale a pena dar uma conferida!


Então é isso, conseguimos dar uma passada bem rápida e legal sobre o tema, e se o post te ajudou de alguma forma, compartilhe e comente se já sabia de alguma dessas informações e quem sabe eu faça mais alguns posts sobre acessibilidade. Podemos até aprofundar em algum dos temas citados neste post!

Obrigado por ler!


Como melhorar a acessibilidade de seus sites


## Introdução

![Imagem de um sitemap do UX Collective](/assets/img/sitemap.png)

O cenário era o seguinte, estava precisando gerar sitemap no Next.JS, mas tinha alguns links que eram totalmente dinâmicos. Sempre que um post novo no blog fosse criado, deveria atualizar o sitemap.

Comecei a buscar algumas soluções e sem sucesso, só conseguia gerar o sitemap estático, e teria de complementar na mão com os paths dinâmicos, além de ser muita gambiarra.

### next-sitemap

Bom, primeiramente vamos instalar a lib. Caso queira usá-lo para gerar apenas páginas estáticas instale-o como devDependencies `-D`

```bash
yarn add next-sitemap
```

### Criando sitemap estático

Agora vamos criar o script. Vá no `package.json` e crie o script `"postbuild": "next-sitemap"`, assim, sempre depois do build ele irá criar o sitemap.

Crie um arquivo `next-sitemap.js` na raiz do seu projeto.
Nele iremos configurar algumas coisas

```js
module.exports = {
  siteUrl: 'https://urldoseu.site',
  generateRobotsTxt: true, // opcional
  priority: null,
  changefreq: null,
  exclude: ['/server-sitemap.xml', '/post/*'],
  robotsTxtOptions: {
    additionalSitemaps: ['https://urldoseu.site/server-sitemap.xml'],
  },
}
```

Bom, a lib irá gerar seu robots.txt também, caso não queira, basta passar como `false`. Os campos *priority* e *changefreq* são campos do xml, no meu caso eu não quero esses dois campos.

Os campos `exclude` e `robotsTxtOptions` não serão necessários caso você queira apenas gerar o sitemap estático.
Caso você tenha algum blog ou páginas que são criadas dinamicamentes, continua aí que vamos ver agora como fazer para preencher o sitemap com eles!

### Criando sitemap dinâmico

Agora iremos criar um arquivo em `pages/server-sitemap.xml/index.tsx`.

Nesse arquivo iremos fazer o seguinte:

```ts
import { getServerSideSitemap } from 'next-sitemap'
import { GetServerSideProps } from 'next'
import { getAllPosts } from 'services' // Importar a api que cria as páginas dinamicas. Method to source urls from cms

export const getServerSideProps: GetServerSideProps = async (ctx) => {
  // Vou pegar os primeiros 100 posts do meu blog
  const allPosts = await getAllPosts({ per_page: 100 })

  // Vou criar um fields, onde busco o slug da minha resposta
  // E com o slug vou preenchendo dinamicamente cada post que tenho
  const fields = allPosts.data.map(({ slug }) => ({
    loc: `https://urldoseu.site/post/${slug}`,
    lastmod: new Date().toISOString(),
    // changefreq
    // priority
  }))

  return getServerSideSitemap(ctx, fields)
}

// Default export to prevent next.js errors
// eslint-disable-next-line @typescript-eslint/no-empty-function
export default () => {}
```

E é apenas isso.
Lembra lá em cima onde criamos o arquivo `next-sitemap.js`?

Os campos:
```js
  exclude: ['/server-sitemap.xml', '/post/*'],
  robotsTxtOptions: {
    additionalSitemaps: ['https://urldoseu.site/server-sitemap.xml'],
  },
```
`exclude`: estou excluindo do meu sitemap estático qualquer página que ele gere no build relacionado aos posts. Assim evito duplicatas em meu `public/sitemap.xml` gerado no `postbuild` com o meu `server-sitemap.xml` gerado dinamicamente.

Além disso, adiciono o meu `server-sitemap.xml` em meu `robots.txt`.

Quando acessarmos `localhost:3000/server-sitemap.xml` iremos ver o nosso xml dinâmico.

É isso. Geramos nosso xml estático e dinâmico em menos de 10 minutos!

Se o post te ajudou, compartilhe!


Como gerar sitemap estático e dinâmico no Next.JS com o next-sitemap

Como gerar sitemap no Next.JS


## Introduction

A week ago I bought an Echo Dot from Amazon, and since then I've fallen in love with automation.

Today I'll show you how I used scripts to do the automation of some things here.

![Image of an Echo Dot](/assets/img/alexa-echo-dot.jpg)

### TriggerCMD

First, we are going to use TriggerCMD. TRIGGERcmd is a cloud service that allows you to securely and remotely run commands on your computers.

There are many ways to trigger your commands, including IFTTT, Alexa, Google Home, SmartThings, and Zapier.

In this post, we are going to use Alexa.

TriggerCMD works with Windows, Mac and Linux.

#### Creating an account

You need to go to [TriggerCMD login page](https://www.triggercmd.com/user/auth/login).
You can use a different email from your Amazon account. Your TriggerCMD account will be used to link your Amazon account using the TriggerCMD Alexa Skill.

#### Downloading TriggerCMD Agent

After creating an account, download the TriggerCMD Agent for your OS [clicking here.](https://www.triggercmd.com/en/)

Now, go to [TriggerCMD instructions](https://www.triggercmd.com/user/computer/create) and copy your token, it will be used after installing TriggerCMD Agent on your computer

Now that you have linked your TriggerCMD account with your computer using TriggerCMD Agent and your token, you can create some commands and linking it to your Alexa, using TriggerCMD skill!

#### Understanding more about TriggerCMD

You can check [this video](https://www.youtube.com/watch?v=9Jm_s9sTZXw), so you can understand a little better how to sync your account with Alexa Skill and create some commands using TriggerCMD GUI.

#### Creating your commands

![TriggerCMD GUI](/assets/img/trigger-cmd-gui.png)

I have created a command called "work" that runs a `work.bat` file on my PC.

```shell
:: Open project on Code and run dev server
cd C:\www\prion\mainProject
start cmd /k npm run dev
code .
```

That's it. You synchronize a service that is running on your computer that is activated by another one, which in this case is Alexa.

And you can go a little further, like, creating a `.vbs` script that opens Spotify on a specific playlist on your computer and plays it. Like this:

```vb
Set WshShell = WScript.CreateObject("WScript.Shell")
Comandline = "start spotify"
WScript.sleep 5000
CreateObject("WScript.Shell").Run("spotify:playlist:0CtF5Q52iAOxdUkSIh5hBM")
WScript.sleep 3000
WshShell.SendKeys "{ENTER}"
WScript.sleep 1000
WshShell.SendKeys "^{s}"
WScript.sleep 100
WshShell.SendKeys "^{RIGHT}"
```

To open the Spotify playlist you just need to copy the URI :D

That's it for today! I hope I could help you to understand a little bit this world of automation!

Any typos or grammar errors? Let me know in the comments section!

Want to dive a little better on something in this post? Let me know too and I can create another post about it!


How to use shell scripts, vbs and nodejs to automate your computer with Alexa and TriggerCMD

How I automated my PC using Alexa and programming



## Introduction

Today's post is about a cool set up you can do in your projects. It's easier to type out the paths, no more `../../../../where-is-my-folder`

You can move a file without having to update its input paths

## Let's get started!

All you have to do is creating a `jsconfig.json` in your root folder with this code:

```json
{
  "compilerOptions": {
    "baseUrl": "src"
  },
  "include": ["src"]
}
```

Then, you go to your `eslintrc.js` or where you set up your ESlint and create a new object

```js
settings: {
    'import/resolver': {
      node: {
        paths: ['src'],
      },
    },
  },
```

And it's pretty much it! You can now make those imports prettier and easier!

![Comparing the before and after of how imports were made](/assets/img/thumb-absolute-path.png "Comparing the before and after of how imports were made")

**Note that you don't need to install any npm package for this, that settings chunk is enough.**

That was a pretty short post! Any questions let me know in the comments below!

Stick around for more tips!

Thank you for reading!


Configuring absolute path! No more ../../../hell plus ESLint

Absolute imports with Create React App


## Introduction

When I was developing this blog I just knew it had to be responsive, and I know a lot of people have some doubts about what to do.

So today I'm going to show some tips about how to make your site more responsive with pure CSS!

![Image of a mobile, tablet and desktop, introducing to Responsive Subject](/assets/img/responsive-sources.jpg)

### Media queries

I think the biggest question always is: **breakpoints**

**Which ones should I use?**

And I got you. Here are the medias queries breakpoints I use in every project

```json
{
  "huge": "1440px",
  "large": "1170px",
  "medium": "768px",
  "small": "450px"
}
```

You dont have to set a new breakpoint every 100px, if you do, something is wrong with your responsive!

Why I said that?? Mobile-first! Which is our next topic!

### Mobile First

If you start your development in the mobile view your site will become so much responsive!

Adapting to large screens is much easier than adapting large screens to small screens, and mobile access is increasing so much that you don't want to lose their access because your app isn't responsive enough!

### The key to responsive!

On my blog, I just had to use one media query and it was 1170px.

For instance:

My sidebar will be showing at the top on mobile, so, to do that I just created this rule:

```css
@media (max-width: 1170px) {
  .blogWrapper {
    flex-direction: column;
  }
}
```

and now, the key... The secret is to use **REM**. ~~which won't make you [lose your religion](https://youtu.be/xwtdhWltSIg/)~~

I used **rem** in almost everywhere on my blog and it makes the responsive so much easier!

> [Check: Can I Use: REM](https://caniuse.com/#feat=rem)

> Type of unit similar to em, but relative only to the root element, not any parent element.

> Equal to the computed value of font-size on the root element. When specified on the font-size property of the root element, the rem units refer to the property’s initial value.

This means that 1rem equals the font size of the HTML element (which for most browsers has a default value of 16px). Unless you change it 😊

That's it for today! In the next post we will see a lib where we can make our responsive so much fast, so stick around!


How to use media queries and which unit to use to make a better responsive

How to make a responsive website using pure CSS


![Image of "Wello World" in a terminal](/assets/img/hello-world.png)

## I'm not just "a strange man behind the keyboard"

Hey, how are you?
I'm Miguel Machado, a full stack developer **from Brazil**, I have about 2 years of experience in the programming field

I always dreamt about having my blog, so, why not build my own?!

### Why I developed this blog?

I always loved to show others what I've created and what I've learned. _I kinda like the idea of teaching_ **and it's my chance to improve my English!**

### The mission

I'm planning to be publishing at least one post per week.

And I hope I can always bring some content that helps or teaches something!

### What I am going to be blogging about?

I'm going to post about development, some tips I learned during my developer career and the sooner you learn it, the better! And I can't forget **Science**, because, well, I ❤️ Science!

#### Note:

**Any typos or grammar errors? Let me know in the comments section!**

That's it for today, devs! Stick around for more content!


Let me introduce to you. Come, have a sit!

Miguel MachadoSoftware Engineer