Um container Postgres singleton acelera testes de integração em Rust, mas sem ryuk e com statics que nunca são dropados ele vaza para sempre. O problema, a causa raiz e o fix com a crate dtor.

In the [previous article](/pt-BR/posts/testes-integracao-rust-testcontainers), I showed how to write integration tests in Rust using Testcontainers against real Postgres and Redis. It works well, but there's a detail that only showed up once I took the "singleton container" pattern into a real production codebase: if you're not careful, every `cargo test` leaves a zombie Postgres container running on your machine, forever.

It's not a rare bug. It's a direct consequence of how `static` works in Rust, combined with the fact that `testcontainers-rs` — unlike its Java and Go counterparts — has no ryuk-style reaper. Worth understanding before you copy the singleton pattern from the previous article into your own project.

## The pattern that looked right

The idea is simple: instead of booting a fresh container for every test, boot one Postgres container once per test binary and reuse it, giving each test its own isolated database inside it.

```rust
static CONTAINER: OnceCell<(ContainerAsync<Postgres>, u16)> = OnceCell::const_new();

async fn container_port() -> u16 {
    let (_container, port) = CONTAINER
        .get_or_init(|| async {
            let container = Postgres::default()
                .with_tag("16-alpine")
                .start()
                .await
                .expect("postgres container started");
            let port = container
                .get_host_port_ipv4(5432)
                .await
                .expect("postgres port");
            (container, port)
        })
        .await;
    *port
}
```

Each test stays isolated — except instead of paying the full container boot cost (typically 1 to 3 seconds), it only pays for a `CREATE DATABASE`. Across a suite with dozens of tests, the difference is huge.

There's a hidden problem in that `static`, though.

## `static` is never dropped — not even when the process exits

In Rust, values stored in a `static` **never run their destructors**. This has nothing to do with how the process terminates — it doesn't matter whether `main` returns normally or something calls `std::process::exit`. It's a language guarantee: `static` destructors simply don't run.

`ContainerAsync`'s `Drop` impl exists and does the right thing — it calls `docker rm` on the container. The problem is that, stashed inside a `static` `OnceCell`, that `Drop` never fires. Nothing ever removes the container.

In Java and Go, this usually doesn't hurt because Testcontainers runs a companion container called **ryuk**: a reaper that watches the test process's connection and removes orphaned resources when it drops, independent of whether any `Drop`/`finally`/`defer` ran. `testcontainers-rs` **doesn't implement ryuk**. Without it, and without `static` drops, there's no safety net.

The most direct way to confirm this is to run the test suite and count containers before and after:

```bash
docker ps --filter "ancestor=postgres:16-alpine" --format "{{.ID}}" | wc -l
```

Without a fix, that number only grows with every `cargo test`.

## The fix: a real destructor, outside of Rust

Since `Drop` can't be trusted here, the fix is to hook into the actual process exit — at the C runtime level, not Rust's. That's exactly what the [`dtor`](https://docs.rs/dtor) crate is for (destructor support split out of `ctor` as of version 1.0): it registers a function in the binary's `.fini_array` section, which the OS runs on process exit, independent of any Rust-level guarantee.

The important catch: there's no active tokio runtime inside that hook, so you can't just call `ContainerAsync`'s async `Drop` again (it uses `tokio::runtime::Handle::current()` internally and panics without a runtime). The way out is to stash only the container ID as a plain `String` and remove the container with a synchronous `docker rm -f`:

```rust
static CONTAINER_ID: OnceLock<String> = OnceLock::new();

// ... inside the container's get_or_init:
CONTAINER_ID.set(container.id().to_owned()).expect("set once");

#[dtor::dtor]
unsafe fn stop_shared_container() {
    if let Some(id) = CONTAINER_ID.get() {
        let _ = std::process::Command::new("docker")
            .args(["rm", "-f", id])
            .output();
    }
}
```

The crate requires the function to be marked `unsafe fn` — code running before `main` doesn't have the usual Rust runtime guarantees, and the macro warns you about it via a deprecation lint if you don't. After this change, running the full suite and counting containers with `docker ps` shows zero leftovers, whether the run succeeds, a test fails, or the process gets interrupted mid-run.

## Extra gotcha: the singleton is per binary, not per suite

If you're coming from Java or Go, it's easy to assume "singleton container" means one container for the entire `cargo test` run. That's not what happens.

Cargo compiles every file under `tests/` as its own separate test binary, and unit tests inside `src/` (the inline `#[cfg(test)]` ones) compile into yet another, entirely separate binary. A `static` lives at process scope — so "singleton" here means *one container per binary*, not one container per project. A project with unit tests scattered across `src/` and a `tests/integration.rs` will boot at least two containers per full `cargo test` run, not one. That's expected, not a bug, but worth knowing before you're confused seeing more than one container in `docker ps` mid-suite.

## Per-test database instead of per-test transaction

The previous article uses transaction rollback to isolate tests — that works well when each test holds onto a single connection. The problem shows up if your application uses a **real connection pool** (`diesel-async` + `deadpool`, for example): the pool hands out arbitrary connections, so there's no single "the" test connection to roll back.

The alternative that pairs well with a singleton container: instead of a transaction, each test creates its own database inside the shared container.

```rust
let db_name = format!("test_{}", DB_COUNTER.fetch_add(1, Ordering::Relaxed));
diesel::PgConnection::establish(&admin_url)
    .expect("admin connection")
    .batch_execute(&format!(r#"CREATE DATABASE "{db_name}""#))
    .expect("create test database");

let url = format!("postgres://postgres:postgres@127.0.0.1:{port}/{db_name}");
diesel::PgConnection::establish(&url)
    .expect("migration connection")
    .run_pending_migrations(MIGRATIONS)
    .expect("migrations");

let pool = DbPool::new(&DatabaseSettings { url }).expect("test db pool");
```

A `CREATE DATABASE` costs far less than booting a new container, and isolation stays complete: each test gets its own schema, with no shared state between them and no dependency on which connection the pool happened to hand out.

## The payoff

On a real suite with 65 unit tests and 17 integration tests, the unit test binary went down to about 6 seconds and the integration binary to about 3 — each paying the container boot cost **exactly once**, not once per test. And after every run, `docker ps` shows zero orphaned containers.

The singleton container pattern from the previous article is still the right call. It's just that "singleton" in Rust, without the reaper other languages get for free, needs an explicit, real destructor — worth knowing before you find out from `docker system df` quietly growing on your disk.

---

**Additional resources:**

- [dtor — documentation](https://docs.rs/dtor)
- [testcontainers-rs — repository](https://github.com/testcontainers/testcontainers-rs)
- [Previous article: Integration Testing in Rust with Testcontainers](/pt-BR/posts/testes-integracao-rust-testcontainers)


A singleton Postgres container speeds up Rust integration tests, but without ryuk and with statics that never drop, it leaks forever. The problem, the root cause, and the fix using the dtor crate.

The Zombie Container: Your Rust Testcontainers Singleton Is Leaking (and Nobody Tells You)

No [artigo anterior](/pt-BR/posts/testes-integracao-rust-testcontainers), mostrei como escrever testes de integração em Rust usando Testcontainers contra Postgres e Redis reais. Funciona bem, mas tem um detalhe que só apareceu quando levei o padrão "container singleton" para produção: se você não tomar cuidado, cada `cargo test` deixa um container Postgres zumbi rodando na sua máquina, para sempre.

Não é um bug raro. É uma consequência direta de como `static` funciona em Rust, combinada com o fato de que `testcontainers-rs` — ao contrário das versões Java e Go — não tem um reaper estilo ryuk. Vale entender por quê antes de copiar o padrão de singleton do artigo anterior para o seu projeto.

## O padrão que parecia certo

A ideia é simples: em vez de subir um container novo a cada teste, sobe um container Postgres uma vez por binário de teste e reaproveita para todos, criando um banco de dados isolado por teste dentro dele.

```rust
static CONTAINER: OnceCell<(ContainerAsync<Postgres>, u16)> = OnceCell::const_new();

async fn container_port() -> u16 {
    let (_container, port) = CONTAINER
        .get_or_init(|| async {
            let container = Postgres::default()
                .with_tag("16-alpine")
                .start()
                .await
                .expect("postgres container started");
            let port = container
                .get_host_port_ipv4(5432)
                .await
                .expect("postgres port");
            (container, port)
        })
        .await;
    *port
}
```

Cada teste continua isolado — só que em vez de pagar o boot completo do container (tipicamente de 1 a 3 segundos), ele paga apenas o custo de um `CREATE DATABASE`. Numa suíte com dezenas de testes, a diferença é enorme.

Só que tem um problema escondido nesse `static`.

## `static` nunca é dropado — nem quando o processo termina

Em Rust, valores armazenados em `static` **nunca chamam seus destrutores**. Isso não depende de como o processo termina — não importa se o `main` retorna normalmente ou se alguém chama `std::process::exit`. É uma garantia da linguagem: destrutores de `static` simplesmente não rodam.

O `Drop` de `ContainerAsync` existe e faz o trabalho certo — ele chama `docker rm` no container. O problema é que, guardado num `OnceCell` `static`, esse `Drop` nunca é executado. Nada nunca remove o container.

Em Java e Go, isso não costuma doer porque o Testcontainers roda um container companheiro chamado **ryuk**: um reaper que fica de olho na conexão do processo de teste e remove os recursos órfãos quando ela cai, independente de qualquer `Drop`/`finally`/`defer` ter rodado. `testcontainers-rs` **não implementa ryuk**. Sem isso, e sem `Drop` de `static`, não existe rede de segurança.

A forma mais direta de confirmar isso é rodar a suíte de testes e contar containers antes e depois:

```bash
docker ps --filter "ancestor=postgres:16-alpine" --format "{{.ID}}" | wc -l
```

Sem correção, esse número só cresce a cada `cargo test`.

## O fix: um destructor de verdade, fora do Rust

Como não dá para confiar em `Drop`, a solução é interceptar o encerramento real do processo — no nível do runtime C, não do Rust. É exatamente para isso que serve a crate [`dtor`](https://docs.rs/dtor) (a parte de destructors que saiu da `ctor` a partir da versão 1.0): ela registra uma função na seção `.fini_array` do binário, que o sistema operacional executa no encerramento do processo, sem depender de nenhuma garantia da linguagem Rust.

O detalhe importante: dentro desse hook não existe runtime tokio ativo, então não dá para simplesmente chamar o `Drop` assíncrono do `ContainerAsync` de novo (ele usa `tokio::runtime::Handle::current()` internamente e entra em pânico sem um runtime). A saída é guardar só o ID do container como `String` e remover o container via `docker rm -f` diretamente, de forma síncrona:

```rust
static CONTAINER_ID: OnceLock<String> = OnceLock::new();

// ... dentro do get_or_init do container:
CONTAINER_ID.set(container.id().to_owned()).expect("set once");

#[dtor::dtor]
unsafe fn stop_shared_container() {
    if let Some(id) = CONTAINER_ID.get() {
        let _ = std::process::Command::new("docker")
            .args(["rm", "-f", id])
            .output();
    }
}
```

A crate exige que a função seja marcada `unsafe fn` — o próprio código antes de `main` não tem as garantias normais do runtime Rust, e a macro avisa isso via deprecation warning se você não marcar. Depois dessa mudança, rodar a suíte inteira e contar containers com `docker ps` mostra zero sobras, em qualquer cenário: sucesso, teste que falha, ou processo interrompido no meio.

## Pegadinha extra: o singleton é por binário, não por suíte

Se você vem de Java ou Go, é fácil assumir que "container singleton" significa um único container para a rodada inteira de `cargo test`. Não é isso que acontece.

O Cargo compila cada arquivo em `tests/` como um binário de teste separado, e os testes unitários dentro de `src/` (os `#[cfg(test)]` inline) compilam para outro binário totalmente à parte. Um `static` vive no escopo de um processo — então "singleton" aqui quer dizer *um container por binário*, não um container por projeto. Um projeto com testes unitários espalhados pelo `src/` e um `tests/integration.rs` vai, no mínimo, subir dois containers por rodada completa de `cargo test`, não um. Isso é esperado e não é um bug, mas vale saber antes de estranhar ver mais de um container no `docker ps` no meio da suíte.

## Banco por teste em vez de transação por teste

O artigo anterior usa rollback de transação para isolar testes — funciona bem quando cada teste segura uma única conexão. O problema aparece se sua aplicação usa um **pool de conexões de verdade** (`diesel-async` + `deadpool`, por exemplo): o pool entrega conexões arbitrárias, então não existe "a" conexão do teste para dar rollback.

A alternativa que combina bem com o container singleton: em vez de uma transação, cada teste cria seu próprio banco dentro do container compartilhado.

```rust
let db_name = format!("test_{}", DB_COUNTER.fetch_add(1, Ordering::Relaxed));
diesel::PgConnection::establish(&admin_url)
    .expect("admin connection")
    .batch_execute(&format!(r#"CREATE DATABASE "{db_name}""#))
    .expect("create test database");

let url = format!("postgres://postgres:postgres@127.0.0.1:{port}/{db_name}");
diesel::PgConnection::establish(&url)
    .expect("migration connection")
    .run_pending_migrations(MIGRATIONS)
    .expect("migrations");

let pool = DbPool::new(&DatabaseSettings { url }).expect("test db pool");
```

O custo de um `CREATE DATABASE` é muito menor que o de subir um container novo, e o isolamento continua total: cada teste tem seu próprio schema, sem estado compartilhado entre eles, sem depender de qual conexão o pool decidiu entregar.

## Resultado

Numa suíte real com 65 testes unitários e 17 de integração, o binário de testes unitários passou a rodar em cerca de 6 segundos e o de integração em cerca de 3 — cada um pagando o boot do container **uma única vez**, não uma vez por teste. E depois de cada rodada, `docker ps` mostra zero containers órfãos.

O padrão de container singleton do artigo anterior continua sendo o caminho certo. Só que "singleton" em Rust, sem o reaper que outras linguagens têm de graça, exige um destructor explícito de verdade — e vale saber disso antes de descobrir pelo `docker system df` crescendo silenciosamente no seu disco.

---

**Recursos adicionais:**

- [dtor — documentação](https://docs.rs/dtor)
- [testcontainers-rs — repositório](https://github.com/testcontainers/testcontainers-rs)
- [Artigo anterior: Testes de Integração em Rust com Testcontainers](/pt-BR/posts/testes-integracao-rust-testcontainers)


O Container Zumbi: o Testcontainers Singleton em Rust Vaza (e Ninguém te Avisa)

O TimesFM 2.5 reduziu de 500M para 200M parâmetros e expandiu o contexto 8x para 16K. Apache 2.0, roda em CPU e Apple Silicon.

**TimesFM 2.5** from Google Research shrank from 500M to 200M parameters while expanding context 8x to 16K. Decoder-only transformer, pretrained on billions of time-series points, Apache 2.0, runs on CPU through Apple Silicon.

Dropped the frequency indicator that made v2.0 need manual config. Added a 30M quantile head for uncertainty out to 1K horizon. Nixtla's TimeGPT charges per API call for what Google recently open-sourced.

- **License:** Apache 2.0
- **Parameters:** 200M (down from 500M)
- **Context:** 16K (8x increase)

## Repo

**GitHub:** [google-research/timesfm](https://github.com/google-research/timesfm)

`#timesFM` `#timeSeriesAI` `#forecasting` `#foundationModels` `#openSource`


TimesFM 2.5 shrank from 500M to 200M parameters while expanding context 8x to 16K. Apache 2.0, runs on CPU and Apple Silicon.

TimesFM 2.5 — Google's Open-Source Time Series Foundation Model

O **TimesFM 2.5** do Google Research reduziu de 500M para 200M parâmetros enquanto expandia o contexto 8x para 16K. Transformer decoder-only, pré-treinado em bilhões de pontos de séries temporais, Apache 2.0, roda em CPU e Apple Silicon.

Removeu o indicador de frequência que obrigava configuração manual no v2.0. Adicionou uma cabeça quantil de 30M para incerteza em até 1K de horizonte. O TimeGPT da Nixtla cobra por chamada de API pelo que o Google recentemente tornou open source.

- **Licença:** Apache 2.0
- **Parâmetros:** 200M (reduzido de 500M)
- **Contexto:** 16K (aumento de 8x)

## Repositório

**GitHub:** [google-research/timesfm](https://github.com/google-research/timesfm)

`#timesFM` `#timeSeriesAI` `#forecasting` `#foundationModels` `#openSource`


TimesFM 2.5 — Modelo de séries temporais da Google, agora open source

Repo open source que percorre um sistema agêntico de produção com PostgreSQL, rate limiting, circuit breakers, e observabilidade via Prometheus, Grafana e Langfuse.

An open-source repo that walks through a production-grade agentic system built around seven layers. It uses PostgreSQL for persistence, rate limiting and input sanitization for security, circuit breakers for LLM calls, streaming responses, and observability via Prometheus, Grafana, and Langfuse.

The stack is well thought through for data and runtime — worth studying for the semantic layer gap between storage and agent reasoning.

- **Stack:** PostgreSQL · Prometheus · Grafana · Langfuse
- **Patterns:** Rate limiting · Circuit breakers · Streaming · Input sanitization

## Repo

**GitHub:** [FareedKhan-dev/production-grade-agentic-system](https://github.com/FareedKhan-dev/production-grade-agentic-system)

`#agenticAI` `#systemArchitecture` `#semanticLayer` `#AIEngineering`


Open source repo walking through a production-grade agentic system with PostgreSQL, rate limiting, circuit breakers, and observability via Prometheus, Grafana, and Langfuse.

Production Agentic System — Seven-Layer Reference Architecture

Um repo open source que percorre um sistema agêntico de produção construído em torno de sete camadas. Usa PostgreSQL para persistência, rate limiting e sanitização de entrada para segurança, circuit breakers para chamadas LLM, respostas em streaming e observabilidade via Prometheus, Grafana e Langfuse.

O stack é bem pensado para dados e runtime — vale estudar especialmente para entender a lacuna da camada semântica entre armazenamento e raciocínio do agente.

- **Stack:** PostgreSQL · Prometheus · Grafana · Langfuse
- **Padrões:** Rate limiting · Circuit breakers · Streaming · Sanitização de entrada

## Repositório

**GitHub:** [FareedKhan-dev/production-grade-agentic-system](https://github.com/FareedKhan-dev/production-grade-agentic-system)

`#agenticAI` `#systemArchitecture` `#semanticLayer` `#AIEngineering`


Sistema agêntico de produção — Arquitetura de referência com sete camadas

O SimWorld permite soltar agentes Clawbot em uma cidade virtual com física real. Antes de construir um robô de entrega, rode mil dias de navegação urbana em simulação.

**SimWorld** lets you drop Clawbot agents into a virtual city and watch what happens. They wake up, commute, run errands, coordinate with each other — all inside a simulated environment with real physics. Same idea as a flight simulator, but for AI agents.

Before building a delivery robot, run a thousand days of city navigation in simulation first. The architecture is decoupled: swap in your own agent framework without touching the world.

- **Architecture:** Decoupled — swap agent frameworks independently

## Repo

**GitHub:** [SimWorld-AI/SimWorld](https://github.com/SimWorld-AI/SimWorld)

`#EmbodiedAI` `#SimWorld` `#Robotics` `#Simulation` `#OpenSource`


SimWorld lets you drop Clawbot agents into a virtual city with real physics. Before building a delivery robot, run a thousand days of city navigation in simulation first.

SimWorld — Simulate AI Agents in a Virtual City

O **SimWorld** permite que você solte agentes Clawbot em uma cidade virtual e observe o que acontece. Eles acordam, se deslocam, fazem tarefas, coordenam entre si — tudo dentro de um ambiente simulado com física real. Mesma ideia de um simulador de voo, mas para agentes de IA.

Antes de construir um robô de entrega, rode mil dias de navegação urbana em simulação. A arquitetura é desacoplada: troque seu próprio framework de agentes sem tocar no mundo.

- **Arquitetura:** Desacoplada — troque o framework de agentes independentemente

## Repositório

**GitHub:** [SimWorld-AI/SimWorld](https://github.com/SimWorld-AI/SimWorld)

`#EmbodiedAI` `#SimWorld` `#Robotics` `#Simulation` `#OpenSource`


SimWorld — Simule agentes de IA em uma cidade virtual

O repowise indexa seu código em quatro camadas — grafos de dependência, histórico git, docs semânticos e decisões de arquitetura — e as serve via dez ferramentas MCP.

**Repowise** indexes your codebase into four layers: dependency graphs via tree-sitter, git history mining (hotspots, ownership, co-change coupling), auto-generated docs with semantic search, and architectural decision tracking — then serves them through ten MCP tools.

Your agent can query blast radius, trace dead code, or surface why a decision was made without reading a single file. One CLI to index, <30s incremental updates per commit. Open source, self-hosted, 10+ languages.

## Repo

**GitHub:** [repowise-dev/repowise](https://github.com/repowise-dev/repowise)

`#repowise` `#ContextEngineering` `#CodingAgents` `#MCP`


repowise indexes your codebase into four layers — dependency graphs, git history, semantic docs, architectural decisions — and serves them through ten MCP tools.

repowise — Four-Layer Codebase Intelligence via MCP

O **repowise** indexa sua codebase em quatro camadas: grafos de dependência via tree-sitter, mineração de histórico git (hotspots, propriedade, co-change coupling), documentação gerada automaticamente com busca semântica, e rastreamento de decisões de arquitetura — depois serve tudo isso via dez ferramentas MCP.

Seu agente pode consultar raio de impacto de mudanças, rastrear código morto ou descobrir por que uma decisão foi tomada sem ler um único arquivo. Um CLI para indexar, atualizações incrementais em menos de 30s por commit. Open source, self-hosted, mais de 10 linguagens.

## Repositório

**GitHub:** [repowise-dev/repowise](https://github.com/repowise-dev/repowise)

`#repowise` `#ContextEngineering` `#CodingAgents` `#MCP`


repowise — Inteligência de codebase em quatro camadas via MCP

Como o repowise indexa seu repositório uma vez e serve contexto curado via MCP, reduzindo o consumo de tokens em 27x sem perda de qualidade.

A coding agent burns most of its budget re-exploring your repo: grepping for symbols, reading files, re-reading them as context grows. **repowise** does that exploration once, offline, then serves your agent curated answers through MCP.

Loading a commit's context costs 2,391 tokens instead of 64,039 — roughly 27x fewer — at the same answer quality. `pip install`, index once, and it stays in sync per commit.

- **Stars:** 2.8k
- **License:** AGPL-3.0
- **Install:** `pip install repowise`

## Repo

**GitHub:** [repowise-dev/repowise](https://github.com/repowise-dev/repowise)

`#CodingAgents` `#ContextEngineering` `#MCP` `#AIEngineering`


How repowise indexes your repo once offline and serves curated context via MCP, cutting token usage by 27x with no quality loss.

repowise — 27x Fewer Tokens for Coding Agent Context

Um agente de código gasta a maior parte do seu orçamento re-explorando o repositório: buscando símbolos, lendo arquivos, relendo à medida que o contexto cresce. O **repowise** faz essa exploração uma única vez, offline, e depois serve respostas curadas ao seu agente via MCP.

Carregar o contexto de um commit custa 2.391 tokens em vez de 64.039 — cerca de 27x menos — com a mesma qualidade de resposta. `pip install`, indexe uma vez, e ele se mantém sincronizado por commit.

- **Stars:** 2.8k
- **Licença:** AGPL-3.0
- **Instalação:** `pip install repowise`

## Repositório

**GitHub:** [repowise-dev/repowise](https://github.com/repowise-dev/repowise)

`#CodingAgents` `#ContextEngineering` `#MCP` `#AIEngineering`


repowise — 27x menos tokens para agentes de código

O OSM2World converte mais de 250 tags do OpenStreetMap em cenas 3D completas com materiais PBR, exportando glTF, OBJ ou 3D Tiles para CesiumJS e viewers OGC.

OpenStreetMap contributors have been encoding 3D geometry for years — `building:levels`, `roof:shape`, `height` — without a renderer that took those tags seriously. **OSM2World** does.

It parses 250+ OSM keys into full 3D scenes with PBR materials and multi-LOD output, exporting glTF, OBJ, or 3D Tiles. That last format is the strategic one: it pipes volunteer-mapped geometry straight into CesiumJS or any OGC viewer. No proprietary pipeline.

- **Stars:** 698
- **License:** MIT
- **Language:** Java

## Repo

**GitHub:** [tordanik/OSM2World](https://github.com/tordanik/OSM2World)
**Website:** [osm2world.org](https://osm2world.org)

`#OSM2World` `#GeoAI` `#OpenStreetMap` `#3D` `#OpenSource`


OSM2World parses 250+ OSM keys into full 3D scenes with PBR materials, exporting glTF, OBJ, or 3D Tiles for CesiumJS and OGC viewers. No proprietary pipeline.

OSM2World — 3D Renderer for OpenStreetMap

Contribuidores do OpenStreetMap vêm codificando geometria 3D há anos — `building:levels`, `roof:shape`, `height` — sem um renderizador que levasse essas tags a sério. O **OSM2World** faz isso.

Ele converte mais de 250 chaves OSM em cenas 3D completas com materiais PBR e saída multi-LOD, exportando glTF, OBJ ou 3D Tiles. Esse último formato é o estratégico: ele leva a geometria mapeada por voluntários direto para o CesiumJS ou qualquer viewer OGC. Sem pipeline proprietário.

- **Stars:** 698
- **Licença:** MIT
- **Linguagem:** Java

## Repositório

**GitHub:** [tordanik/OSM2World](https://github.com/tordanik/OSM2World)
**Site:** [osm2world.org](https://osm2world.org)

`#OSM2World` `#GeoAI` `#OpenStreetMap` `#3D` `#OpenSource`


OSM2World — Renderizador 3D para OpenStreetMap

O OpenResearcher acerta nas escolhas de design para agentes de deep research: trajetórias longas (100+ turnos), primitivos de navegação explícitos e evals completamente reproduzíveis.

**OpenResearcher** hits several design choices that feel right for deep research agents: long-horizon (100+ turn) trajectories, explicit browsing primitives instead of opaque RAG calls, and fully reproducible evals/logs.

It's a solid reference if you care about agents that actually do research rather than just summarizing the first page of search results.

- **Trajectories:** 100+ turns
- **Approach:** Explicit browsing primitives · reproducible evals

## Repo

**GitHub:** [TIGER-AI-Lab/OpenResearcher](https://github.com/TIGER-AI-Lab/OpenResearcher)

`#AI` `#LLM` `#Agents` `#OpenSource` `#DeepResearch`


OpenResearcher hits the right design choices for deep research agents: 100+ turn trajectories, explicit browsing primitives instead of opaque RAG calls, and reproducible evals.

OpenResearcher — Long-Horizon Deep Research Agent

O **OpenResearcher** acerta em várias escolhas de design que parecem "certas" para agentes de pesquisa profunda: trajetórias de longo prazo (100+ turnos), primitivos de navegação explícitos em vez de chamadas RAG opacas, e evals/logs completamente reproduzíveis.

É uma referência sólida se você se importa com agentes que realmente fazem pesquisa em vez de apenas resumir a primeira página dos resultados de busca.

- **Trajetórias:** 100+ turnos
- **Abordagem:** Primitivos de navegação explícitos · evals reproduzíveis

## Repositório

**GitHub:** [TIGER-AI-Lab/OpenResearcher](https://github.com/TIGER-AI-Lab/OpenResearcher)

`#AI` `#LLM` `#Agents` `#OpenSource` `#DeepResearch`


OpenResearcher — Agente de pesquisa profunda com trajetórias de 100+ turnos

O OpenMetadata conecta todos os seus data warehouses, bancos de dados e ferramentas de BI, construindo um grafo de metadados unificado de cada tabela, coluna, dashboard e pipeline.

**OpenMetadata** is an open-source platform that connects to all your warehouses, databases, BI tools, and pipelines, building a unified metadata graph of every table, column, dashboard, job, and model in your company.

With that graph, you can follow end-to-end lineage in seconds to see what breaks before you change a field, attach data quality tests where they matter, route incidents to the right owners, and give AI copilots safe, well-described tables to query instead of a swamp of unnamed datasets.

Integrates with Airflow, Kafka, Spark, Snowflake, BigQuery, Looker, Power BI, and more.

## Repo

**GitHub:** [open-metadata/OpenMetadata](https://github.com/open-metadata/OpenMetadata)

`#DataEngineering` `#DataGovernance` `#DataLineage` `#AIInfrastructure`


OpenMetadata connects all your warehouses, databases, and BI tools, building a unified metadata graph of every table, column, dashboard, and pipeline across your company.

OpenMetadata — Unified Metadata Graph for Data Platforms

O **OpenMetadata** é uma plataforma open source que conecta todos os seus data warehouses, bancos de dados, ferramentas de BI e pipelines, construindo um grafo de metadados unificado de cada tabela, coluna, dashboard, job e modelo na empresa.

Com esse grafo, você pode seguir lineage de ponta a ponta em segundos para ver o que quebra antes de mudar um campo, anexar testes de qualidade de dados onde importam, rotear incidentes para os donos certos e dar a copilots de IA tabelas bem descritas em vez de um pântano de datasets sem nome.

Integra com Airflow, Kafka, Spark, Snowflake, BigQuery, Looker, Power BI e mais.

## Repositório

**GitHub:** [open-metadata/OpenMetadata](https://github.com/open-metadata/OpenMetadata)

`#DataEngineering` `#DataGovernance` `#DataLineage` `#AIInfrastructure`


OpenMetadata — Grafo unificado de metadados para plataformas de dados

O Ollama-OCR envolve cinco modelos de visão em uma API instalável via pip que retorna JSON, pares chave-valor ou dados tabulares. Sem custos de API, sem dados saindo da sua máquina.

**Ollama-OCR** wraps five vision models behind one pip-installable API that outputs JSON, key-value pairs, or tabular data directly from the extraction call. No downstream parsing, no API costs, nothing leaves your machine.

Point it at a folder of invoices or scanned contracts, get structured data back with parallel processing and progress tracking. The right abstraction for document pipelines is structure at extraction time, not flat text plus post-processing.

- **Install:** `pip install ollama-ocr`
- **Models:** 5 vision models supported
- **Output:** JSON · key-value · tabular

## Repo

**GitHub:** [imanoop7/Ollama-OCR](https://github.com/imanoop7/Ollama-OCR)

`#OllamaOCR` `#DocumentAI` `#LocalFirst` `#AIEngineering` `#OpenSource`


Ollama-OCR wraps five vision models in a pip-installable API that outputs JSON, key-value pairs, or tabular data. No API costs, nothing leaves your machine.

Ollama-OCR — Local Vision OCR with Structured Output

O **Ollama-OCR** envolve cinco modelos de visão em uma API instalável via pip que retorna JSON, pares chave-valor ou dados tabulares diretamente da chamada de extração. Sem parsing downstream, sem custos de API, nada sai da sua máquina.

Aponte para uma pasta de faturas ou contratos digitalizados, obtenha dados estruturados de volta com processamento paralelo e rastreamento de progresso. A abstração certa para pipelines de documentos é estrutura no momento da extração, não texto plano mais pós-processamento.

- **Instalação:** `pip install ollama-ocr`
- **Modelos:** 5 modelos de visão suportados
- **Saída:** JSON · chave-valor · tabular

## Repositório

**GitHub:** [imanoop7/Ollama-OCR](https://github.com/imanoop7/Ollama-OCR)

`#OllamaOCR` `#DocumentAI` `#LocalFirst` `#AIEngineering` `#OpenSource`


Ollama-OCR — OCR local com modelos de visão e saída estruturada

O mem0 CLI colapsa toda a infraestrutura de memória de agentes em um install. Armazene, busque e escopie preferências por usuário ou agente com recuperação sub-milissegundo.

Agent memory usually means wiring SDKs, spinning up databases, building retrieval pipelines before your agent remembers anything. **mem0 CLI** collapses that to one install.

Store a preference, search it back next session, scope it per user or agent so nothing bleeds across tenants. Accepts text, files, or stdin. Sub-millisecond retrieval. JSON output so agents can call it as a subprocess.

- **Install:** `npm install -g @mem0/cli` or `pip install mem0-cli`

## Repo

**GitHub:** [mem0ai/mem0](https://github.com/mem0ai/mem0)

`#mem0` `#agentMemory` `#CLI` `#agenticAI` `#contextEngineering`


mem0 CLI collapses all agent memory infrastructure into one install. Store, search, and scope preferences per user or agent with sub-millisecond retrieval.

mem0 CLI — One-Command Agent Memory

Memória de agente geralmente significa conectar SDKs, subir bancos de dados, construir pipelines de recuperação antes do seu agente lembrar qualquer coisa. O **mem0 CLI** colapsa isso em um único install.

Armazene uma preferência, busque-a de volta na próxima sessão, escope-a por usuário ou agente para que nada vaze entre tenants. Aceita texto, arquivos ou stdin. Recuperação sub-milissegundo. Saída JSON para que agentes possam chamá-lo como subprocess.

- **Instalação:** `npm install -g @mem0/cli` ou `pip install mem0-cli`

## Repositório

**GitHub:** [mem0ai/mem0](https://github.com/mem0ai/mem0)

`#mem0` `#agentMemory` `#CLI` `#agenticAI` `#contextEngineering`


mem0 CLI — Memória de agente em um único comando

O mcp-cli chama servidores MCP com descoberta dinâmica em vez de carregar todos os schemas upfront, mantendo o contexto do agente enxuto.

**mcp-cli** is a lightweight way to call MCP servers without blowing up your context window, using dynamic discovery instead of loading every tool schema upfront.

You can integrate it directly via system instructions or as an Agent Skill so AI coding agents can discover servers, inspect tools, and execute commands on demand.

- **Discovery:** Dynamic — no upfront schema loading
- **Integration:** System instructions · Agent Skills

## Repo

**GitHub:** [philschmid/mcp-cli](https://github.com/philschmid/mcp-cli)

`#MCP` `#AIAgents` `#DevTools` `#LLM` `#OpenSource`


mcp-cli calls MCP servers with dynamic discovery instead of loading all tool schemas upfront, keeping agent context lean.

mcp-cli — Lightweight MCP Server Client Without Context Bloat

O **mcp-cli** é uma forma leve de chamar servidores MCP sem explodir sua janela de contexto, usando descoberta dinâmica em vez de carregar todos os schemas de ferramentas antecipadamente.

Você pode integrá-lo diretamente via instruções de sistema ou como um Agent Skill para que agentes de código de IA possam descobrir servidores, inspecionar ferramentas e executar comandos sob demanda.

- **Descoberta:** Dinâmica — sem carregamento antecipado de schemas
- **Integração:** Instruções de sistema · Agent Skills

## Repositório

**GitHub:** [philschmid/mcp-cli](https://github.com/philschmid/mcp-cli)

`#MCP` `#AIAgents` `#DevTools` `#LLM` `#OpenSource`


mcp-cli — Cliente leve para servidores MCP sem explodir o contexto

O Handy v0.9.0 trouxe suporte a modelos de streaming, então o texto aparece enquanto você fala. Totalmente local, sem cloud, 25.5k stars.

**Handy** v0.9.0 changes the feel of local speech-to-text: streaming model support landed, so text forms while you talk instead of after you release the key.

The Nemotron streaming model keeps a rolling cache across audio chunks, so accuracy holds at the chunk boundaries where most on-device streaming degrades. Still fully local, no cloud.

- **Stars:** 25.5k
- **License:** MIT

## Repo

**GitHub:** [cjpais/Handy](https://github.com/cjpais/Handy)

`#SpeechToText` `#LocalFirst` `#OpenSource` `#OnDeviceAI`


Handy v0.9.0 brings streaming model support so text forms while you talk. Fully local, no cloud, 25.5k stars, MIT.

Handy v0.9.0 — Local Streaming Speech-to-Text

O **Handy** v0.9.0 muda completamente a experiência de speech-to-text local: suporte a modelos de streaming chegou, então o texto se forma enquanto você fala, em vez de aparecer só depois de soltar a tecla.

O modelo Nemotron streaming mantém um cache contínuo entre chunks de áudio, então a precisão se mantém nas bordas dos chunks — exatamente onde a maioria dos sistemas de streaming on-device degrada. Ainda completamente local, sem cloud.

- **Stars:** 25.5k
- **Licença:** MIT

## Repositório

**GitHub:** [cjpais/Handy](https://github.com/cjpais/Handy)

`#SpeechToText` `#LocalFirst` `#OpenSource` `#OnDeviceAI`


Handy v0.9.0 — Speech-to-text local com streaming em tempo real

O Flowsint transforma workflows OSINT de planilhas em grafos visuais. Domínios, IPs, orgs, wallets e emails viram nós expandíveis com transforms como WHOIS, subdomains e breaches.

Most OSINT workflows still look like spreadsheets: lists of domains, IPs, emails. **Flowsint** flips that into a graph. Domains, IPs, orgs, wallets, emails, trackers become nodes and edges you can expand with transforms (WHOIS, subdomains, breaches, Maigret, crawlers) in a visual canvas.

Local-first (Docker, Postgres, Neo4j), open-source, and feels like a modern, self-hosted Maltego for security and threat-intel teams.

- **Stack:** Docker · PostgreSQL · Neo4j
- **Transforms:** WHOIS · subdomains · breaches · Maigret · crawlers

## Repo

**GitHub:** [reconurge/flowsint](https://github.com/reconurge/flowsint)

`#osint` `#cybersecurity` `#knowledgegraph` `#threatintel`


Flowsint turns OSINT workflows from spreadsheets into visual graphs. Domains, IPs, orgs, wallets, emails become expandable nodes with WHOIS, subdomain, and breach transforms.

Flowsint — Self-Hosted Open Source OSINT Graph Tool

A maioria dos workflows OSINT ainda parece planilhas: listas de domínios, IPs, emails. O **Flowsint** inverte isso em um grafo. Domínios, IPs, orgs, wallets, emails, trackers se tornam nós e arestas que você pode expandir com transforms (WHOIS, subdomínios, breaches, Maigret, crawlers) em um canvas visual.

Local-first (Docker, Postgres, Neo4j), open source, e parece um Maltego moderno e self-hosted para equipes de segurança e threat intel.

- **Stack:** Docker · PostgreSQL · Neo4j
- **Transforms:** WHOIS · subdomínios · breaches · Maigret · crawlers

## Repositório

**GitHub:** [reconurge/flowsint](https://github.com/reconurge/flowsint)

`#osint` `#cybersecurity` `#knowledgegraph` `#threatintel`


Flowsint — Ferramenta OSINT em grafo, self-hosted e open source

O fairchem da Meta FAIR usa redes neurais para prever propriedades moleculares e rastrear milhões de catalisadores para armazenamento de energia renovável, transformando semanas de trabalho em horas.

**fairchem** is an open-source library from Meta FAIR that leverages neural networks to predict molecular properties and screen millions of catalysts for renewable energy storage — turning weeks of lab work into hours of computation.

Integrates with PyTorch, ASE for atomic simulations, and RDKit for chemistry workflows, enabling breakthroughs in hydrogen batteries, CO2 capture, and solar efficiency.

- **Integrations:** PyTorch · ASE · RDKit
- **Applications:** Hydrogen batteries · CO2 capture · solar efficiency

## Repo

**GitHub:** [facebookresearch/fairchem](https://github.com/facebookresearch/fairchem)

`#ClimateAI` `#NeuralNetworks` `#RenewableEnergy` `#Sustainability`


Meta FAIR's fairchem uses neural networks to predict molecular properties and screen millions of catalysts for renewable energy storage, turning weeks of lab work into hours.

fairchem — Neural Networks for Materials Science and Climate AI

O **fairchem** é uma biblioteca open source da Meta FAIR que usa redes neurais para prever propriedades moleculares e rastrear milhões de catalisadores para armazenamento de energia renovável — transformando semanas de trabalho de laboratório em horas de computação.

Integra com PyTorch, ASE para simulações atômicas e RDKit para workflows de química, viabilizando avanços em baterias de hidrogênio, captura de CO2 e eficiência solar.

- **Integrações:** PyTorch · ASE · RDKit
- **Aplicações:** Baterias de hidrogênio · captura de CO2 · eficiência solar

## Repositório

**GitHub:** [facebookresearch/fairchem](https://github.com/facebookresearch/fairchem)

`#ClimateAI` `#NeuralNetworks` `#RenewableEnergy` `#Sustainability`


fairchem — Redes neurais para ciência de materiais e clima

O docling-mcp envolve o Docling da IBM como uma ferramenta MCP padrão: instale com uvx, conecte ao Claude ou LM Studio, e seu agente obtém JSON estruturado com ordem de leitura e extração de tabelas.

PDF parsing is the undocumented dependency every RAG pipeline grows around. **docling-mcp** wraps IBM's Docling as a standard MCP tool: install with `uvx mcp-server-docling`, connect Claude or LM Studio, and your agent calls `convert_document` to get structured JSON with reading order, table extraction, and section hierarchy intact.

Flat text extraction was always the wrong abstraction for document-aware agents.

- **Install:** `uvx mcp-server-docling`
- **Output:** Structured JSON · reading order · tables · section hierarchy

## Repo

**GitHub:** [docling-project/docling-mcp](https://github.com/docling-project/docling-mcp)

`#MCP` `#DocumentAI` `#RAG` `#AIEngineering` `#OpenSource`


docling-mcp wraps IBM's Docling as a standard MCP tool: install with uvx, connect Claude or LM Studio, and your agent gets structured JSON with reading order and table extraction.

docling-mcp — IBM Docling as an MCP Tool for Document-Aware Agents

Parsing de PDF é a dependência não documentada em torno da qual todo pipeline RAG cresce. O **docling-mcp** envolve o Docling da IBM como uma ferramenta MCP padrão: instale com `uvx mcp-server-docling`, conecte ao Claude ou LM Studio, e seu agente chama `convert_document` para obter JSON estruturado com ordem de leitura, extração de tabelas e hierarquia de seções intacta.

Extração de texto plano sempre foi a abstração errada para agentes conscientes de documentos.

- **Instalação:** `uvx mcp-server-docling`
- **Saída:** JSON estruturado · ordem de leitura · tabelas · hierarquia de seções

## Repositório

**GitHub:** [docling-project/docling-mcp](https://github.com/docling-project/docling-mcp)

`#MCP` `#DocumentAI` `#RAG` `#AIEngineering` `#OpenSource`


docling-mcp — IBM Docling como ferramenta MCP para agentes

O ctx armazena suas transcrições completas do Claude Code, Codex e Cursor em SQLite e as pesquisa quando você solicita, retornando correspondências ranqueadas com IDs de sessão.

Your coding agent forgets last week's work and repeats mistakes you already fixed. Saving short memory summaries loses the specifics: the exact command, the failed attempt.

**ctx** keeps your full local Claude Code, Codex, and Cursor transcripts in SQLite and searches them when you ask, returning ranked matches with session IDs the agent can cite. Nothing important gets summarized away.

- **Stars:** 464 (early repo)
- **License:** Apache-2.0

## Repo

**GitHub:** [ctxrs/ctx](https://github.com/ctxrs/ctx)

`#ClaudeCode` `#AgentMemory` `#ContextEngineering` `#OpenSource`


ctx keeps your full Claude Code, Codex, and Cursor transcripts in SQLite and searches them on demand, returning ranked matches with session IDs agents can cite.

ctx — Full Transcript Search for Coding Agents

Seu agente de código esquece o trabalho da semana passada e repete erros que você já corrigiu. Salvar resumos curtos de memória perde os detalhes específicos: o comando exato, a tentativa falha.

O **ctx** mantém suas transcrições completas locais do Claude Code, Codex e Cursor em SQLite e as pesquisa quando você pede, retornando correspondências ranqueadas com IDs de sessão que o agente pode citar. Nada importante é resumido e perdido.

- **Stars:** 464 (repo em desenvolvimento)
- **Licença:** Apache-2.0

## Repositório

**GitHub:** [ctxrs/ctx](https://github.com/ctxrs/ctx)

`#ClaudeCode` `#AgentMemory` `#ContextEngineering` `#OpenSource`


ctx — Busca em transcrições completas para agentes de código

O claude-reflect captura as correções que você dá ao Claude Code, atribui pontuações de confiança e garante que seu CLAUDE.md nunca fique cheio de instruções desatualizadas.

Bayram Annakov's **claude-reflect** captures the corrections you give Claude Code and, before writing anything permanent, makes you review it. Learnings carry confidence scores, decay over time, and get de-duplicated so your `CLAUDE.md` doesn't fill up with stale, contradictory instructions.

Corrections route into the specific skill file they fix, and it writes to `AGENTS.md` too, so the memory travels across Codex and Cursor.

- **Stars:** 1.1k
- **License:** MIT

## Repo

**GitHub:** [BayramAnnakov/claude-reflect](https://github.com/BayramAnnakov/claude-reflect)

`#ClaudeCode` `#AgentMemory` `#CodingAgents` `#AIEngineering`


claude-reflect captures the corrections you give Claude Code, assigns confidence scores, and keeps your CLAUDE.md clean of stale contradictory instructions.

claude-reflect — Self-Learning Memory for Claude Code

O **claude-reflect** de Bayram Annakov captura as correções que você dá ao Claude Code e, antes de escrever qualquer coisa permanente, faz você revisar. Os aprendizados carregam pontuações de confiança, decaem ao longo do tempo e são desduplicados para que seu `CLAUDE.md` não fique cheio de instruções obsoletas e contraditórias.

As correções são roteadas para o arquivo de skill específico que elas corrigem, e também escreve no `AGENTS.md`, então a memória viaja pelo Codex e Cursor.

- **Stars:** 1.1k
- **Licença:** MIT

## Repositório

**GitHub:** [BayramAnnakov/claude-reflect](https://github.com/BayramAnnakov/claude-reflect)

`#ClaudeCode` `#AgentMemory` `#CodingAgents` `#AIEngineering`


claude-reflect — Memória que aprende com suas correções no Claude Code

Florian Bruniaux destilou seis meses de uso diário do Claude Code em 22K linhas de documentação, 204 templates e 271 questões de quiz, com 41 diagramas Mermaid.

Florian Bruniaux's **claude-code-ultimate-guide** distills six months of daily Claude Code practice into 22K lines of documentation, 204 production templates, and 271 quiz questions.

TDD/BDD/SDD workflows, multi-agent architectures with 41 Mermaid diagrams, a security section mapping 24 CVEs and 655 malicious skills, and an MCP server installable with one command. Every section teaches the reasoning behind the pattern.

- **License:** Open source
- **Contents:** 22K lines · 204 templates · 271 quizzes · 41 diagrams

## Repo

**GitHub:** [FlorianBruniaux/claude-code-ultimate-guide](https://github.com/FlorianBruniaux/claude-code-ultimate-guide)

`#ClaudeCode` `#AIEngineering` `#AgenticAI` `#OpenSource`


Florian Bruniaux distilled six months of daily Claude Code practice into 22K lines of docs, 204 production templates, and 271 quiz questions with 41 Mermaid diagrams.

claude-code-ultimate-guide — 204 Production Templates for Claude Code

O **claude-code-ultimate-guide** de Florian Bruniaux destila seis meses de prática diária com Claude Code em 22K linhas de documentação, 204 templates de produção e 271 questões de quiz.

Workflows TDD/BDD/SDD, arquiteturas multi-agente com 41 diagramas Mermaid, uma seção de segurança mapeando 24 CVEs e 655 skills maliciosas, e um servidor MCP instalável com um comando. Cada seção ensina o raciocínio por trás do padrão.

- **Licença:** Open source
- **Conteúdo:** 22K linhas · 204 templates · 271 quizzes · 41 diagramas

## Repositório

**GitHub:** [FlorianBruniaux/claude-code-ultimate-guide](https://github.com/FlorianBruniaux/claude-code-ultimate-guide)

`#ClaudeCode` `#AIEngineering` `#AgenticAI` `#OpenSource`


claude-code-ultimate-guide — 204 templates de produção para Claude Code

O Caveman instrui seu agente de código a escrever como um telegrama, cortando tokens de saída em 65% sem mudança de arquitetura. 8.6k stars.

Julius Brussee's **Caveman** tells your coding agent to write like a telegram — and that cuts output tokens by 65%. No architecture change, no caching layer — just shorter sentences.

A bug explanation that normally runs 1,180 tokens shrinks to 159 with the same fix. Three compression levels from clean prose to near-shorthand. A March 2026 paper found that forcing brevity improved model accuracy by 26 percentage points. Works across Claude Code, Cursor, Copilot, Windsurf, and Codex.

- **Stars:** 8.6k

## Repo

**GitHub:** [JuliusBrussee/caveman](https://github.com/JuliusBrussee/caveman)

`#tokenOptimization` `#claudeCode` `#agenticAI` `#contextEngineering`


Caveman tells your coding agent to write like a telegram, cutting output tokens by 65% with no architecture change. 8.6k stars.

Caveman — 65% Token Reduction for Coding Agents

O **Caveman** de Julius Brussee diz ao seu agente de código para escrever como um telegrama — e isso reduz os tokens de saída em 65%. Sem mudança de arquitetura, sem camada de cache — apenas frases mais curtas.

Uma explicação de bug que normalmente tem 1.180 tokens encolhe para 159 com a mesma correção. Três níveis de compressão, do texto limpo ao quase-abreviado. Um artigo de março de 2026 descobriu que forçar brevidade melhorou a precisão do modelo em 26 pontos percentuais. Funciona com Claude Code, Cursor, Copilot, Windsurf e Codex.

- **Stars:** 8.6k

## Repositório

**GitHub:** [JuliusBrussee/caveman](https://github.com/JuliusBrussee/caveman)

`#tokenOptimization` `#claudeCode` `#agenticAI` `#contextEngineering`


Caveman — 65% menos tokens para agentes de código

O ai-knowledge-graph transforma texto bruto em mapas de conhecimento interativos extraindo triplas SPO, padronizando entidades e inferindo links ocultos.

AI is great at answering questions, but terrible at showing how ideas connect. **ai-knowledge-graph** turns raw text into interactive knowledge maps: it chunks documents, extracts SPO triples with tailored prompts, standardizes entities, and infers hidden links.

Performance and token cost scale with your LLM backend, chunk size, and enabled inference passes.

- **Approach:** SPO triple extraction · entity standardization · hidden link inference
- **Output:** Interactive knowledge maps

## Repo

**GitHub:** [robert-mcdermott/ai-knowledge-graph](https://github.com/robert-mcdermott/ai-knowledge-graph)

`#KnowledgeGraph` `#LLM` `#AI` `#DataVisualization` `#OpenSource`


ai-knowledge-graph turns raw text into interactive knowledge maps by extracting SPO triples, standardizing entities, and inferring hidden links.

ai-knowledge-graph — Interactive Knowledge Maps from Raw Text

IA é ótima em responder perguntas, mas terrível em mostrar como ideias se conectam. O **ai-knowledge-graph** transforma texto bruto em mapas de conhecimento interativos: fragmenta documentos, extrai triplas SPO com prompts personalizados, padroniza entidades e infere links ocultos.

Performance e custo de tokens escalam com seu backend LLM, tamanho do chunk e passes de inferência habilitados.

- **Abordagem:** Extração de triplas SPO · padronização de entidades · inferência de links ocultos
- **Saída:** Mapas de conhecimento interativos

## Repositório

**GitHub:** [robert-mcdermott/ai-knowledge-graph](https://github.com/robert-mcdermott/ai-knowledge-graph)

`#KnowledgeGraph` `#LLM` `#AI` `#DataVisualization` `#OpenSource`


ai-knowledge-graph — Mapas de conhecimento interativos a partir de texto bruto

Aprenda a escrever testes de integração confiáveis para APIs Rust usando Testcontainers, PostgreSQL e Redis com isolamento completo

Learn to write reliable integration tests for Rust APIs using Testcontainers, PostgreSQL and Redis with complete isolation

How to Write Integration Tests for Rust APIs with Testcontainers

Como Escrever Testes de Integração para APIs Rust com Testcontainers

Um guia completo dos aliases do plugin Git do Oh My Zsh para aumentar sua produtividade no terminal


If you use Git daily, you know how some commands can be repetitive and lengthy. The Oh My Zsh Git plugin offers over 200 aliases that transform extensive commands into 2-4 character shortcuts, saving time and significantly boosting your productivity.

In this post, I'll show you the most common and useful aliases you should know.

## Basic Commands

These are the fundamental aliases you'll use every day:

- `g` = `git`
- `gst` = `git status`
- `gss` = `git status --short`
- `gsb` = `git status --short --branch`

Instead of typing `git status` all the time, just use `gst`. Simple as that!

## Add & Commit

Shortcuts for adding files and making commits:

- `ga` = `git add`
- `gaa` = `git add --all`
- `gc` = `git commit --verbose`
- `gcmsg` = `git commit --message`
- `gca` = `git commit --verbose --all`
- `gcam` = `git commit --all --message`
- `gca!` = `git commit --verbose --all --amend`

**Practical example:**

```bash # Traditional way git add --all git commit -m "feat: add new feature"
# With aliases gaa gcmsg "feat: add new feature"
# Or all at once gcam "feat: add new feature" ```

## Branch Operations

Managing branches becomes much faster:

- `gb` = `git branch`
- `gba` = `git branch --all`
- `gbd` = `git branch --delete`
- `gco` = `git checkout`
- `gcb` = `git checkout -b`
- `gcm` = `git checkout $(git_main_branch)`
- `gsw` = `git switch`
- `gswc` = `git switch --create`

**Tip:** The `gcm` alias automatically detects if your main branch is `main`, `master`, or another common name.

```bash # Create and switch to new branch gcb feature/new-feature
# Go back to main/master gcm
# Delete branch gbd feature/old-feature ```

## Push & Pull

Syncing with remote repositories:

- `gp` = `git push`
- `gl` = `git pull`
- `gpsup` = `git push --set-upstream origin $(git_current_branch)`
- `ggpush` = `git push origin "$(git_current_branch)"`
- `ggpull` = `git pull origin "$(git_current_branch)"`
- `gpr` = `git pull --rebase`

**Common usage:**

```bash # First time pushing a new branch gpsup
# Simple push gp
# Pull with rebase gpr ```

## Diff & Log

Viewing differences and commit history:

- `gd` = `git diff`
- `gdca` = `git diff --cached`
- `gds` = `git diff --staged`
- `glo` = `git log --oneline --decorate`
- `glog` = `git log --oneline --decorate --graph`
- `glol` = `git log --graph --pretty=...` (with colors and dates)

The `glol` alias is particularly useful because it shows a colorful and readable formatted log:

```bash # Simple log glo
# Log with visual graph glog
# Detailed and beautiful log glol ```

## Stash

Managing temporary changes:

- `gsta` = `git stash push`
- `gstp` = `git stash pop`
- `gstaa` = `git stash apply`
- `gstl` = `git stash list`

```bash # Store changes temporarily gsta
# View stash list gstl
# Recover last stash gstp ```

## Other Useful Aliases

Additional commands that boost your productivity:

- `gf` = `git fetch`
- `gfa` = `git fetch --all --tags --prune`
- `gm` = `git merge`
- `grb` = `git rebase`
- `grbi` = `git rebase --interactive`
- `grt` = `cd "$(git rev-parse --show-toplevel)"` (go to repo root)

The `grt` alias is especially useful when you're in some subdirectory of the project and want to quickly return to the root.

## How to Start Using

If you use Oh My Zsh, the Git plugin is already enabled by default. Otherwise, add it to your `.zshrc`:

```bash plugins=(git) ```

## Final Tips

1. **Start small**: Don't try to memorize all aliases at once. Start with the most used ones (gst, gaa, gcam, gp, gl)

2. **Keep a cheatsheet**: While you don't memorize them, keep a list of the aliases you use most

3. **Explore gradually**: As you feel comfortable, incorporate new aliases into your workflow

4. **Check the complete list**: The plugin file contains over 200 aliases. Explore it at `~/.oh-my-zsh/plugins/git/git.plugin.zsh`

## Conclusion

Oh My Zsh Git plugin aliases may seem confusing at first, but once you get used to them, it's hard to go back to typing the full commands. They save time, reduce typos, and make your Git workflow much smoother.

Start incorporating some aliases into your daily routine and, in no time, you'll be using them naturally. Your productivity will thank you!

---

**Additional resources:**

- [Oh My Zsh Git Plugin](https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git)
- [Oh My Zsh Official Documentation](https://github.com/ohmyzsh/ohmyzsh)


A complete guide to Oh My Zsh Git plugin aliases to boost your terminal productivity

Oh My Zsh Git Aliases - Complete Guide to Most Used Shortcuts


Se você usa Git diariamente, sabe como alguns comandos podem ser repetitivos e longos. O plugin Git do Oh My Zsh oferece mais de 200 aliases que transformam comandos extensos em atalhos de 2-4 caracteres, economizando tempo e aumentando significativamente sua produtividade.

Neste post, vou mostrar os aliases mais comuns e úteis que você deve conhecer.

## Comandos Básicos

Estes são os aliases fundamentais que você usará todos os dias:

- `g` = `git`
- `gst` = `git status`
- `gss` = `git status --short`
- `gsb` = `git status --short --branch`

Em vez de digitar `git status` toda hora, basta usar `gst`. Simples assim!

## Add & Commit

Atalhos para adicionar arquivos e fazer commits:

- `ga` = `git add`
- `gaa` = `git add --all`
- `gc` = `git commit --verbose`
- `gcmsg` = `git commit --message`
- `gca` = `git commit --verbose --all`
- `gcam` = `git commit --all --message`
- `gca!` = `git commit --verbose --all --amend`

**Exemplo prático:**

```bash # Forma tradicional git add --all git commit -m "feat: add new feature"
# Com aliases gaa gcmsg "feat: add new feature"
# Ou tudo de uma vez gcam "feat: add new feature" ```

## Operações com Branches

Gerenciar branches fica muito mais rápido:

- `gb` = `git branch`
- `gba` = `git branch --all`
- `gbd` = `git branch --delete`
- `gco` = `git checkout`
- `gcb` = `git checkout -b`
- `gcm` = `git checkout $(git_main_branch)`
- `gsw` = `git switch`
- `gswc` = `git switch --create`

**Dica:** O alias `gcm` automaticamente detecta se sua branch principal é `main`, `master` ou outro nome comum.

```bash # Criar e trocar para nova branch gcb feature/nova-funcionalidade
# Voltar para main/master gcm
# Deletar branch gbd feature/antiga ```

## Push & Pull

Sincronização com repositórios remotos:

- `gp` = `git push`
- `gl` = `git pull`
- `gpsup` = `git push --set-upstream origin $(git_current_branch)`
- `ggpush` = `git push origin "$(git_current_branch)"`
- `ggpull` = `git pull origin "$(git_current_branch)"`
- `gpr` = `git pull --rebase`

**Uso comum:**

```bash # Primeira vez fazendo push de uma nova branch gpsup
# Push simples gp
# Pull com rebase gpr ```

## Diff & Log

Visualizar diferenças e histórico de commits:

- `gd` = `git diff`
- `gdca` = `git diff --cached`
- `gds` = `git diff --staged`
- `glo` = `git log --oneline --decorate`
- `glog` = `git log --oneline --decorate --graph`
- `glol` = `git log --graph --pretty=...` (com cores e datas)

O alias `glol` é particularmente útil porque mostra um log colorido e formatado de forma legível:

```bash # Log simples glo
# Log com grafo visual glog
# Log detalhado e bonito glol ```

## Stash

Gerenciar mudanças temporárias:

- `gsta` = `git stash push`
- `gstp` = `git stash pop`
- `gstaa` = `git stash apply`
- `gstl` = `git stash list`

```bash # Guardar mudanças temporariamente gsta
# Ver lista de stashes gstl
# Recuperar último stash gstp ```

## Outros Aliases Úteis

Comandos adicionais que aumentam sua produtividade:

- `gf` = `git fetch`
- `gfa` = `git fetch --all --tags --prune`
- `gm` = `git merge`
- `grb` = `git rebase`
- `grbi` = `git rebase --interactive`
- `grt` = `cd "$(git rev-parse --show-toplevel)"` (ir para raiz do repo)

O alias `grt` é especialmente útil quando você está em algum subdiretório do projeto e quer voltar rapidamente para a raiz.

## Como Começar a Usar

Se você usa Oh My Zsh, o plugin Git já está habilitado por padrão. Caso contrário, adicione-o ao seu `.zshrc`:

```bash plugins=(git) ```

## Dicas Finais

1. **Comece aos poucos**: Não tente memorizar todos os aliases de uma vez. Comece com os mais usados (gst, gaa, gcam, gp, gl)

2. **Mantenha um cheatsheet**: Enquanto não memoriza, mantenha uma lista dos aliases que usa mais

3. **Explore gradualmente**: À medida que se sentir confortável, incorpore novos aliases ao seu workflow

4. **Consulte a lista completa**: O arquivo do plugin contém mais de 200 aliases. Explore em `~/.oh-my-zsh/plugins/git/git.plugin.zsh`

## Conclusão

Os aliases do plugin Git do Oh My Zsh podem parecer confusos no início, mas uma vez que você se acostuma, é difícil voltar a digitar os comandos completos. Eles economizam tempo, reduzem erros de digitação e tornam seu fluxo de trabalho com Git muito mais fluido.

Comece incorporando alguns aliases no seu dia a dia e, em pouco tempo, você estará usando-os naturalmente. Sua produtividade agradece!

---

**Recursos adicionais:**

- [Plugin Git do Oh My Zsh](https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git)
- [Documentação oficial do Oh My Zsh](https://github.com/ohmyzsh/ohmyzsh)


Oh My Zsh Git Aliases - Guia Completo dos Atalhos Mais Usados

Traducao em portugues da newsletter This Week in Rust 643

*Original post: [https://this-week-in-rust.org/blog/2026/03/18/this-week-in-rust-643/](https://this-week-in-rust.org/blog/2026/03/18/this-week-in-rust-643/)*

This Week in Rust 643

Traducao em portugues da newsletter This Week in Rust 642

*Original post: [https://this-week-in-rust.org/blog/2026/03/11/this-week-in-rust-642/](https://this-week-in-rust.org/blog/2026/03/11/this-week-in-rust-642/)*

This Week in Rust 642

Traducao em portugues da newsletter This Week in Rust 641

*Original post: [https://this-week-in-rust.org/blog/2026/03/04/this-week-in-rust-641/](https://this-week-in-rust.org/blog/2026/03/04/this-week-in-rust-641/)*

This Week in Rust 641

Traducao em portugues da newsletter This Week in Rust 640

## Original post: <https://this-week-in-rust.org/blog/2026/02/25/this-week-in-rust-640/>

This Week in Rust 640

Essa semana com Rust 640

Guia completo para configurar e testar seu controle Xbox One no Arch Linux usando o driver xpad

# How to Setup Xbox One Controller on Arch Linux (Omarchy)

Hey there! So you're trying to game on Linux with your Xbox One controller but things aren't working out? Don't worry, I recently went through this myself and I'll show you how to fix it super easily.

## The Problem

Here's the deal: you plug in your controller via USB, Linux even recognizes that something's plugged in, but the specific Xbox controller driver (the `xpad` one) doesn't load automatically. The result? The hardware is detected but your games can't actually use it. Pretty annoying, right?

## Let's Check if the Controller is Being Detected

First things first: let's make sure Linux can at least see your controller. Run this in your terminal:

```bash
lsusb
```

Look for a line like this:
```
Bus 003 Device 004: ID 045e:02d1 Microsoft Corp. Xbox One Controller
```

Found it? Awesome! The hardware is connected properly.

## Is the xpad Driver There?

Good news: Linux already comes with the `xpad` driver out of the box, but it needs to be manually loaded. Let's check if it's available on your system:

```bash
modinfo xpad
```

This command will show you a bunch of info about the driver - where it's installed, which devices it supports, that kind of stuff.

## Time to Load the Driver

Here comes the magic. Run this command:

```bash
sudo modprobe xpad
```

To confirm it worked, check with:

```bash
lsmod | grep xpad
```

If you see something like:
```
xpad                   49152  0
ff_memless             20480  1 xpad
```

Then success! The driver is running.

## Checking if the Joystick Showed Up

With the driver running, your controller should show up as a joystick device. Let's check:

```bash
ls -la /dev/input/js*
```

You should see something like `/dev/input/js0`. To be 100% sure it's the Xbox, run:

```bash
cat /sys/class/input/js0/device/name
```

If Let's Test This Thing!

Now for the fun part: let's test if all the buttons and analog sticks are working. First, install `jstest` (if you don't have it):

```bash
yay -S joyutils
# or if you prefer
sudo pacman -S joyutils
```

Now run the test:

```bash
jstest /dev/input/js0
```

You'll see a real-time interface showing:
- **8 axes**: Both analog sticks, the triggers (RT/LT), and the D-pad
- **11 buttons**: A, B, X, Y, LB, RB, Select, Start, the Xbox button, and the stick clicks

Start pressing buttons and moving the sticks to see the values changing on screen. It's pretty satisfying to see everything working, trust me

Press buttons and move the analog sticks to see the values changing. This confirms everything is working!

## Making It Load Automatically at Boot

Look, running `modprobe` every time you start your PC is a pain in the ass, right? Let's make it automatic:

```bash
echo "xpad" | sudo tee /etc/modules-load.d/xpad.conf
```

Done! This creates a file that tells the system: "hey, load this driver when you boot up".

## What You Got Working

When everything's configured, your controller has:
- **Driver**: xpad (version 2.1.0+)
- **Axes**: 8 (basically the analog sticks, triggers, and D-pad)
- **Buttons**: 11 (all Xbox controller buttons)
- **Rumble**: Yep, it works! (via ff-memless module)

## What If Something Goes Wrong?

### Controller doesn't show up in /dev/input/js0
- Unplug and plug it back in after loading the driver
- Check if the USB cable isn't busted (test it on another device)
- Try a different USB port, sometimes the port itself is acting up

### xpad driver won't load
- Make sure you're using sudo (you need admin permissions)
- The module should come pre-installed on Arch, but you never know

### Some buttons don't respond
- Use `jstest` to see exactly which buttons/axes are having issues
- Might be a hardware problem with the controller itself, test it on another computer

## Where Does It Work?

After it's set up, your controller will work on:
- **Steam**: Auto-detects it, it's beautiful
- **Lutris**: Works like a charm
- **Wine/Proton**: No problems at all
- **Emulators**: RetroArch, PCSX2, Dolphin, all good!

## Wrapping It Up

Look, setting up an Xbox controller on Arch is way easier than it seems. It's basically just loading the right driver and you're done. Linux has really solid support for Xbox controllers, so once you set it up once, it'll work smoothly with almost everything.

**Command cheat sheet to save:**
```bash
# Check if controller is connected
lsusb | grep Xbox

# Load the driver
sudo modprobe xpad

# Check joystick device
ls -la /dev/input/js*

# Test controller
jstest /dev/input/js0

# Auto-load on boot
echo "xpad" | sudo tee /etc/modules-load.d/xpad.conf
```

Now you're ready to play! 🎮


Complete guide to configure and test your Xbox One controller on Arch Linux using the xpad driver

How to Setup Xbox One Controller on Arch Linux (Omarchy)

# Como Configurar Controle Xbox One no Arch Linux (Omarchy)

Fala, pessoal! Então, você tá tentando jogar no Linux com seu controle Xbox One mas tá dando ruim? Relaxa, que eu passei por isso recentemente e vou te mostrar como resolver de forma bem simples.

## O Problema

Olha, a parada é assim: você conecta o controle no USB, o Linux até reconhece que tem alguma coisa plugada ali, mas o driver específico pra controle Xbox (o tal do `xpad`) não carrega sozinho. Resultado? O hardware tá lá, detectado, mas seu jogo não consegue usar ele. Chato demais, né?

## Bora Ver se o Controle Tá Sendo Detectado

Primeiro passo: vamos confirmar que o Linux pelo menos tá vendo teu controle. Roda isso no terminal:

```bash
lsusb
```

Procura por uma linha tipo essa:
```
Bus 003 Device 004: ID 045e:02d1 Microsoft Corp. Xbox One Controller
```

Achou? Show de bola! O hardware tá conectado direitinho.

## E Esse Driver xpad, Tá Aí?

A boa notícia é que o Linux já vem com o driver `xpad` de fábrica, só que ele precisa ser carregado manualmente. Vamos checar se ele tá disponível no sistema:

```bash
modinfo xpad
```

Esse comando vai mostrar um monte de info sobre o driver - onde ele tá instalado, quais dispositivos ele suporta, essas coisas.

## Hora de Carregar o Driver

Agora vem a mágica. Roda esse comando aqui:

```bash
sudo modprobe xpad
```

Pra confirmar que deu certo, cola isso:

```bash
lsmod | grep xpad
```

Se aparecer algo tipo:
```
xpad                   49152  0
ff_memless             20480  1 xpad
```

Então é sucesso! O driver tá rodando.

## Verificando se o Joystick Apareceu

Com o driver rodando, teu controle deve aparecer como um dispositivo joystick. Vamos checar:

```bash
ls -la /dev/input/js*
```

Deve aparecer algo tipo `/dev/input/js0`. Pra ter 100% de certeza que é o Xbox, roda:

```bash
cat /sys/class/input/js0/device/name
```

Se Vamos Testar Esse Bicho!

Agora a parte divertida: vamos testar se todos os botões e analógicos tão funcionando. Primeiro, instala o `jstest` (se já não tiver):

```bash
yay -S joyutils
# ou se preferir
sudo pacman -S joyutils
```

Agora roda o teste:

```bash
jstest /dev/input/js0
```

Vai aparecer uma interface em tempo real mostrando:
- **8 eixos**: Os dois analógicos, os gatilhos (RT/LT) e o D-pad
- **11 botões**: A, B, X, Y, LB, RB, Select, Start, o botão do Xbox e os cliques dos analógicos

Vai apertando os botões e mexendo nos analógicos pra ver os valores mudando na tela. É satisfatório ver tudo funcionando, confia

Pressione os botões e mova os analógicos para ver os valores mudando. Isso confirma que tudo está funcionando!

## Fazendo Carregar Sozinho na Inicialização

Olha, ficar rodando `modprobe` toda vez que ligar o PC é chato pra cacete, né? Vamos fazer isso automaticamente:

```bash
echo "xpad" | sudo tee /etc/modules-load.d/xpad.conf
```

Pronto! Isso cria um arquivo que fala pro sistema: "ó, carrega esse driver aí quando iniciar".

## O Que Você Conseguiu

Quando tá tudo configurado, seu controle tem:
- **Driver**: xpad (versão 2.1.0+)
- **Eixos**: 8 (basicamente os analógicos, gatilhos e D-pad)
- **Botões**: 11 (todos os botões do controle Xbox)
- **Vibração**: Sim, funciona! (via módulo ff-memless)

## E Se Algo Der Errado?

### O controle não aparece em /dev/input/js0
- Tira o cabo e conecta de novo depois de carregar o driver
- Testa se o cabo USB não tá ruim (tenta em outro dispositivo)
- Muda de porta USB, as vezes a porta que tá bugada

### O driver xpad não quer carregar
- Confere se tá usando sudo (precisa de permissão de administrador)
- O módulo deveria vir instalado por padrão no Arch, mas nunca se sabe né

### Alguns botões não respondem
- Usa o `jstest` pra ver exatamente quais botões/eixos tão com problema
- Pode ser problema no controle mesmo, testa em outro computador

## Onde Funciona?

Depois de configurado, seu controle vai funcionar em:
- **Steam**: Já detecta sozinho, é lindo
- **Lutris**: Funciona de boa
- **Wine/Proton**: Tranquilo demais
- **Emuladores**: RetroArch, PCSX2, Dolphin, tudo de boa!

## Resumindo Tudo

Olha, configurar o controle Xbox no Arch é bem mais tranquilo do que parece. É basicamente carregar o driver certo e pronto. O Linux tem um suporte muito bom pra controles Xbox, então depois que configurar uma vez, vai funcionar de boa em quase tudo.

**Cola de comandos pra você salvar:**
```bash
# Ver se o controle tá conectado
lsusb | grep Xbox

# Carregar o driver
sudo modprobe xpad

# Ver o dispositivo joystick
ls -la /dev/input/js*

# Testar o controle
jstest /dev/input/js0

# Fazer carregar sozinho no boot
echo "xpad" | sudo tee /etc/modules-load.d/xpad.conf
```

Agora é só partir pro abraço! 🎮


Como Configurar Controle Xbox One no Arch Linux (Omarchy)

Comprei uma ranger 1995 v6, vai que a IA acaba com os devs pelo menos ai eu viro mecanico 

I bought a 1995 Ranger V6, maybe the AI ​​will wipe out the developers, at least then I'll become a mechanic.

I bought a 1995 Ranger V6

Comprei uma ranger 1995 v6

Você tá consumindo um endpoint GraphQL e retorno tem "edges" e "node". Você tá fornecendo uma estrutura JSON limpa pra consulta e parece que o WPGraphQL está poluindo seus dados sem nenhum benefício óbvio aparente. E se pergunta por que esses termos estão incluídos na resposta do endpoint GraphQL e se é possível se livrar deles para um retorno mais simples de dados??


## O que é GraphQL e por que está bombando?

Já falei sobre no post anterior mas se você não leu imagina só: você tá num buffet self-service top da cidade (para quem é de Porto Alegre esses tão escassos hoje em dia). Em vez de pegar aquele prato feito que vem com um monte de coisa que você nem come (como acontece às vezes com APIs REST), você monta exatamente o que quer comer. Style, né? Pois é assim que funciona o GraphQL. Você pede só os dados que precisa, nada a mais, nada a menos. Resultado? Seu site fica mais rápido e você economiza dados. Todo mundo sai ganhando!

## WPGraphQL: Quando o WordPress entra na dança

Agora, pensa no seu site WordPress. Tem post, página, comentário, usuário... uma porrada de coisa. Já falamos também no outro artigo, que o WPGraphQL é um plugin que traz toda essa mágika 🪄 do GraphQL pro WordPress.

## Edges e Nodes: Os inseparáveis do GraphQL

Quando a gente começa a brincar com WPGraphQL, logo esbarra em dois conceitos: edges e nodes. Parece complicado, mas é mais simples do que parece:

- **Nodes**: São os dados mesmo. Um post, um comentário, um usuário. É a informação que você quer pegar.
- **Edges**: É o caminho pra chegar nessa informação. Parece desnecessário, mas pelo visto não é pois::: paginação e metadados.

É tipo uma árvore genealógica. Os nodes são as pessoas, e as edges são as linhas que conectam elas.

## Na prática, como fica?

Vamos ver um exemplo rapidinho de como buscar posts no WPGraphQL:

```graphql
query {
  posts(first: 5) {
    edges {
      node {
        title
        excerpt
      }
    }
  }
}
```

Aqui a gente tá pedindo os 5 primeiros posts, mas só o título e o resumo de cada um. Simples, né?

## Quando usar cada coisa?

- **Lista simples**: Quando você só quer uma lista rápida e direta, sem frescura.
- **Só Nodes**: Útil pra quando você quer paginar, mas não precisa de informações extras sobre cada item.
- **Edges e Nodes**: O pacote completo. Ideal pra quando você precisa de paginação avançada ou metadados sobre cada item da lista.

# Descomplicando o GraphQL no WordPress: Minha Experiência com WPGraphQL

[Conteúdo anterior permanece o mesmo...]

## Quando usar cada coisa?

Galera, vamos ver na prática quando usar cada tipo de estrutura. Colei aqui uns exemplos pra ficar mais fácil de entender:

1. **Lista simples**: Quando você só quer uma lista rápida e direta, sem frescura.

Exemplo: Pegar o nome e o slug das 5 primeiras categorias.

```graphql
query {
  categories(first: 5) {
    name
    slug
  }
}
```

Sacou? Direto ao ponto, sem edges nem nodes. Só o que a gente precisa.

2. **Só Nodes**: Útil pra quando você quer paginar, mas não precisa de informações extras sobre cada item.

Exemplo: Buscar os 10 posts mais recentes, com opção de paginação.

```graphql
query {
  posts(first: 10) {
    nodes {
      title
      date
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}
```

Aqui a gente já tá usando paginação, mas ainda tá bem enxuto, sacou?

3. **Edges e Nodes**: O pacote completo. Ideal pra quando você precisa de paginação avançada ou metadados sobre cada item da lista.

Exemplo: Pegar os 5 primeiros posts, incluindo informações sobre a posição de cada post na lista.

```graphql
query {
  posts(first: 5) {
    edges {
      node {
        title
        excerpt
      }
      cursor
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}
```

Bem chic né?! Agora temos o 'cursor' pra cada post, que é aquela informação extra que falei. Dá pra fazer umas mágicas de paginação avançada com isso.

No WPGraphQL, você vai ver muito o uso de edges e nodes. Pode parecer exagero às vezes, mas essa padronização parece facilitar muito quando o projeto cresce.

## Concluindo...

GraphQL e WPGraphQL podem parecer um bicho de sete cabeças no começo, mas quando a ficha cai, você vê o tanto de possibilidades que se abrem. É uma ferramenta poderosa que dá mais controle e eficiência pro seu desenvolvimento.

Escrevi esse artigo porque é algo que estava nas minhas anotações dessa seman e to tentando colocar mais ideias e pesquisas minhas aqui.

Tem alguma experiência pra compartilhar ou dúvida pra tirar? Comenta aí embaixo! Vamos trocar uma ideia e aprender juntos.

Falou, jovens! Boa semana!


You're consuming a GraphQL endpoint and the return has "edges" and "node". You're providing a clean JSON structure for the query and it seems like WPGraphQL is polluting your data without any obvious benefit. And you wonder why these terms are included in the GraphQL endpoint response and if it's possible to get rid of them for a simpler data return?

Demystifying GraphQL in WordPress: What do "edges" and "node" mean?

Descomplicando o GraphQL no WordPress: qual é o significado de "edges" e "node"?

Imagina que você conseguiu um cliente e esse cliente tem um site wordpress, mas você não trabalha com wordpress e ainda assim quer fechar o contrato, o que você faz? Bom, foi o que aconteceu comigo e pode acontecer com você, então nesse post vamos conversar um pouco sobre esse estudo de caso.


E aí, galera! Tô aqui pra contar uma parada bem louca que rolou comigo recentemente. Vocês não vão acreditar!

- Como eu decidi se valia a pena entrar nessa roubada (spoiler: tá indo!)
- A inspiração que me levou pro caminho do WordPress headless
- O que é WordPress headless e por que é uma boa
- As opções pra fazer o WordPress virar headless: REST API vs WPGraphQL
- As vantagens do WPGraphQL e por que eu escolhi ele

Se você já se viu numa saia justa parecida, ou só tá curioso pra saber como foi, cola aqui! Vamos trocar uma ideia sobre como a gente pode se virar nos trinta quando aparece um projeto fora da nossa zona de conforto.

Bora lá?

## Como eu decidi se valia a pena entrar nessa roubada

Então, galera, é o seguinte: caiu no meu colo um cliente, vamos chamar ele de _N_, que tem um site/blog com mais de 15 anos de postagens e muitos acessos diários. Eu já atendia eles faz um tempo pra umas coisinhas pequenas, mas a ideia de desenvolver um novo site, que já tava sem atualização há anos, tava sempre no ar.

As negociações começaram em fevereiro de 2024, mas o projeto só começou a rolar mesmo há alguns meses. E aí vem o pepino: o site todo era WordPress. Pra quem não manja, WordPress é "um programa de código aberto que você pode usar pra criar um site, blog ou aplicativo bem legal sem muito sofrimento".

Meu único contato com WordPress foi lá na adolescência, quando eu tinha um blog pra escrever minhas noias. Migrei pra lá depois de deletar sem querer meu Blogspot (sim, foi muito clicar sem ler, achei que tava fazendo backup, quase chorei). Depois que virei desenvolvedor, sempre ouvi falar de WP e sei que grande parte da web ainda usa ele. Pelo menos 80% da web roda em PHP (pra nossa tristeza, né? kkkkk). Mentira, respeito PHP, sempre vou respeitar coisas sólidas.

Então, por que raios eu aceitei esse desafio? Simples: porque eu posso e tenho um "probleminha" na cabeça onde tô constantemente me desafiando. Já me ferrei muito por isso, mas faz parte do aprendizado, né?

## O desafio: WordPress Headless

No fim das contas, decidimos que poderíamos ficar com WordPress, mas também tentar migrar pra uma stack nova. Aí que o bicho pegou: como fazer essa comunicação se vamos manter o WP como CMS (Content Management System) e fazer um site à parte?

O requisito era: "não podemos perder essa base de dados". E eu também não queria fazer uma migração pra outro lugar, o que ia deixar tudo mais caro pro cliente e dar mais trabalho pra mim.

Aí me veio uma ideia maluca: e se a gente usasse o WordPress como headless? Pois é, galera, tô falando de WordPress headless! Mas calma aí, vou explicar melhor essa parada.

## A inspiração: Strapi e CMS Headless

Antes de seguir, deixa eu contar uma história que me ajudou a chegar nessa solução. Em 2021, um brother meu, o @felipe marcolin, me falou sobre um tema que ficou martelando na minha cabeça. Ele mencionou o Strapi, que é um "CMS headless de última geração, de código aberto e javascript, que permite que experiências ricas em conteúdo sejam criadas, gerenciadas e expostas a qualquer dispositivo digital."

Achei a ideia tão foda que fui atrás de um curso pra aprender mais. Acabei caindo num curso do William Justen em 2022. Esse cara é brabo e muito didático, um diferencial na comunidade. Lá aprendi mais sobre Strapi e sobre a melhor versão do app. Hoje em dia, na v4, eu não curto tanto porque eles fecharam muito o opensource e não dá pra customizar tanto, mas ainda é uma solução animal pra colocar rápido em produção.

E aí que tá a sacada: um CMS headless é basicamente um sistema de gerenciamento de conteúdo da web só de backend, que funciona principalmente como um repositório de conteúdo. Isso me fez pensar: será que dá pra fazer isso com WordPress?

## WordPress headless: o que é isso?

![Arquitetura de como o WordPress headless funciona.](https://kinsta.com/wp-content/uploads/2023/11/headless-cms-arcitecture.png "Arquitetura de como o WordPress headless funciona. (https://kinsta.com/pt/blog/wpgraphql-e-wp-rest-api/)")

Então, o WordPress normal não é um CMS headless de cara. Ele é aquele CMS que todo mundo conhece, fácil de usar e flexível pra criar e gerenciar conteúdo. Mas tradicionalmente, ele mistura o gerenciamento de conteúdo com a forma de apresentar esse conteúdo, tudo num pacote só.

Mas aí os developers malucos criaram o tal do WordPress headless usando a API REST dele. Nesse esquema, o WordPress continua sendo o CMS onde você cria, gerencia e guarda o conteúdo. A diferença é que, em vez de mostrar o site direto pelos templates e temas do WordPress, a parte do frontend fica separada do backend.

Isso permite que a gente construa aplicativos usando tecnologias e frameworks diferentes, mas ainda aproveitando as paradas legais de gerenciamento de conteúdo do WordPress. É um jeito de fazer o WordPress funcionar mais como headless, mesmo não sendo a configuração padrão.

## As opções: REST API vs WPGraphQL

### REST API do WordPress

A API REST é tipo o coringa do WordPress. Desde a versão 4.7, ela já vem embutida e não precisa de plugin nenhum pra funcionar. Com ela, você consegue pegar os dados do seu site no formato JSON.

Pra usar, é só adicionar /wp-json ao URL do site:

```
http://seusite.com/wp-json
```

Daí você tem endpoints pra posts, páginas, comentários, mídia e por aí vai. Por exemplo:

```
http://seusite.com/wp-json/wp/v2/posts
http://seusite.com/wp-json/wp/v2/comments
http://seusite.com/wp-json/wp/v2/media
```

### WPGraphQL

Agora, se você quer uma parada mais moderna e eficiente, tem o WPGraphQL. É um plugin baseado em GraphQL que permite fazer consultas mais precisas e personalizadas.

![Plugin WpGraphQL no mercado do WP.](https://kinsta.com/wp-content/uploads/2023/11/wpgraphql-plugin.png "Plugin WpGraphQL no mercado do WP.")

![Obtenha dados de artigos do WordPress com o WPGraphQL.](https://kinsta.com/wp-content/uploads/2023/11/testing-graphql-wp.jpg "Obtenha dados de artigos do WordPress com o WPGraphQL.")

Com o WPGraphQL, você tem um único endpoint e pode pedir exatamente os dados que precisa, sem ficar pegando um monte de coisa que não vai usar. Por exemplo:

```graphql
{
  post(id: "123") {
    title
    content
    comments {
      edges {
        node {
          content
        }
      }
    }
  }
}
```

Nesse exemplo, a gente tá pegando o título, conteúdo e comentários de um post específico, tudo numa tacada só!

## As vantagens do WPGraphQL

Galera, deixa eu falar mais sobre o WPGraphQL, porque essa parada é muito massa:

1. Endpoint único pra recuperação precisa de dados: Com o WPGraphQL, você tem um endpoint unificado, tipo `/graphql`, que te permite pegar exatamente os dados que você precisa. É bem diferente da API REST, onde você precisa fazer várias chamadas pra pegar tudo que quer.

2. Consultas direcionadas pra uma recuperação eficiente: Com o GraphQL, você pode criar consultas específicas pro que você precisa. Isso evita que você pegue um monte de dado que não vai usar. Por exemplo:

```graphql
{
  posts {
    title
    date
    author {
      name
    }
  }
}
```

Nessa consulta, a gente tá pegando só o título, a data e o nome do autor dos posts. Nada de informação extra que a gente não vai usar!

3. Vários recursos raiz: No WPGraphQL, você pode consultar vários recursos de uma vez só. Tipo, você pode pegar posts e páginas numa única consulta:

```graphql
{
  posts {
    edges {
      node {
        title
        content
      }
    }
  }

  pages {
    edges {
      node {
        title
        content
      }
    }
  }
}
```

Isso deixa tudo mais rápido e eficiente.

## Qual escolher?

Bom, galera, a escolha entre REST API e WPGraphQL vai depender do que você precisa pro seu projeto. Se quer uma solução já integrada no WordPress, vai de REST API. Se quer algo mais moderno e eficiente, o WPGraphQL pode ser uma boa.

No fim das contas, o importante é escolher a ferramenta que melhor se encaixa no seu fluxo de trabalho e nas metas do projeto. Assim você garante uma integração suave entre o WordPress e o framework de frontend que você escolher.

No meu caso, acabei optando pelo WPGraphQL pra fazer a POC (Proof of Concept) pro nosso cliente N. A ideia era usar o WordPress como backend pra alimentar nosso frontend em Next.js, que a gente escolheu pra ajudar no SEO, que era o grande foco do projeto.

E aí, o que acharam dessa lourada? Já passaram por algo parecido? Conta aí nos comentários! Até a próxima, galera!


Imagine you got a client and this client has a WordPress site, but you don't work with WordPress and still want to close the deal, what do you do? Well, that's what happened to me and it can happen to you, so in this post let's talk a bit about this case study

Dealing with WordPress Projects When You're Not an Expert: WPGraphQL or REST API for Headless WordPress

E aí, galera! Tô aqui pra contar uma parada bem louca que rolou comigo recentemente. Vocês não vão acreditar!

- Como eu decidi se valia a pena entrar nessa roubada (spoiler: tá indo!)
- A inspiração que me levou pro caminho do WordPress headless
- O que é WordPress headless e por que é uma boa
- As opções pra fazer o WordPress virar headless: REST API vs WPGraphQL
- As vantagens do WPGraphQL e por que eu escolhi ele

Se você já se viu numa saia justa parecida, ou só tá curioso pra saber como foi, cola aqui! Vamos trocar uma ideia sobre como a gente pode se virar nos trinta quando aparece um projeto fora da nossa zona de conforto.

Bora lá?

## Como eu decidi se valia a pena entrar nessa roubada

Então, galera, é o seguinte: caiu no meu colo um cliente, vamos chamar ele de _N_, que tem um site/blog com mais de 15 anos de postagens e muitos acessos diários. Eu já atendia eles faz um tempo pra umas coisinhas pequenas, mas a ideia de desenvolver um novo site, que já tava sem atualização há anos, tava sempre no ar.

As negociações começaram em fevereiro de 2024, mas o projeto só começou a rolar mesmo há alguns meses. E aí vem o pepino: o site todo era WordPress. Pra quem não manja, WordPress é "um programa de código aberto que você pode usar pra criar um site, blog ou aplicativo bem legal sem muito sofrimento".

Meu único contato com WordPress foi lá na adolescência, quando eu tinha um blog pra escrever minhas noias. Migrei pra lá depois de deletar sem querer meu Blogspot (sim, foi muito clicar sem ler, achei que tava fazendo backup, quase chorei). Depois que virei desenvolvedor, sempre ouvi falar de WP e sei que grande parte da web ainda usa ele. Pelo menos 80% da web roda em PHP (pra nossa tristeza, né? kkkkk). Mentira, respeito PHP, sempre vou respeitar coisas sólidas.

Então, por que raios eu aceitei esse desafio? Simples: porque eu posso e tenho um "probleminha" na cabeça onde tô constantemente me desafiando. Já me ferrei muito por isso, mas faz parte do aprendizado, né?

## O desafio: WordPress Headless

No fim das contas, decidimos que poderíamos ficar com WordPress, mas também tentar migrar pra uma stack nova. Aí que o bicho pegou: como fazer essa comunicação se vamos manter o WP como CMS (Content Management System) e fazer um site à parte?

O requisito era: "não podemos perder essa base de dados". E eu também não queria fazer uma migração pra outro lugar, o que ia deixar tudo mais caro pro cliente e dar mais trabalho pra mim.

Aí me veio uma ideia maluca: e se a gente usasse o WordPress como headless? Pois é, galera, tô falando de WordPress headless! Mas calma aí, vou explicar melhor essa parada.

## A inspiração: Strapi e CMS Headless

Antes de seguir, deixa eu contar uma história que me ajudou a chegar nessa solução. Em 2021, um brother meu, o @felipe marcolin, me falou sobre um tema que ficou martelando na minha cabeça. Ele mencionou o Strapi, que é um "CMS headless de última geração, de código aberto e javascript, que permite que experiências ricas em conteúdo sejam criadas, gerenciadas e expostas a qualquer dispositivo digital."

Achei a ideia tão foda que fui atrás de um curso pra aprender mais. Acabei caindo num curso do William Justen em 2022. Esse cara é brabo e muito didático, um diferencial na comunidade. Lá aprendi mais sobre Strapi e sobre a melhor versão do app. Hoje em dia, na v4, eu não curto tanto porque eles fecharam muito o opensource e não dá pra customizar tanto, mas ainda é uma solução animal pra colocar rápido em produção.

E aí que tá a sacada: um CMS headless é basicamente um sistema de gerenciamento de conteúdo da web só de backend, que funciona principalmente como um repositório de conteúdo. Isso me fez pensar: será que dá pra fazer isso com WordPress?

## WordPress headless: o que é isso?

![Arquitetura de como o WordPress headless funciona.](https://kinsta.com/wp-content/uploads/2023/11/headless-cms-arcitecture.png "Arquitetura de como o WordPress headless funciona. (https://kinsta.com/pt/blog/wpgraphql-e-wp-rest-api/)")

Então, o WordPress normal não é um CMS headless de cara. Ele é aquele CMS que todo mundo conhece, fácil de usar e flexível pra criar e gerenciar conteúdo. Mas tradicionalmente, ele mistura o gerenciamento de conteúdo com a forma de apresentar esse conteúdo, tudo num pacote só.

Mas aí os developers malucos criaram o tal do WordPress headless usando a API REST dele. Nesse esquema, o WordPress continua sendo o CMS onde você cria, gerencia e guarda o conteúdo. A diferença é que, em vez de mostrar o site direto pelos templates e temas do WordPress, a parte do frontend fica separada do backend.

Isso permite que a gente construa aplicativos usando tecnologias e frameworks diferentes, mas ainda aproveitando as paradas legais de gerenciamento de conteúdo do WordPress. É um jeito de fazer o WordPress funcionar mais como headless, mesmo não sendo a configuração padrão.

## As opções: REST API vs WPGraphQL

### REST API do WordPress

A API REST é tipo o coringa do WordPress. Desde a versão 4.7, ela já vem embutida e não precisa de plugin nenhum pra funcionar. Com ela, você consegue pegar os dados do seu site no formato JSON.

Pra usar, é só adicionar /wp-json ao URL do site:

```
http://seusite.com/wp-json
```

Daí você tem endpoints pra posts, páginas, comentários, mídia e por aí vai. Por exemplo:

```
http://seusite.com/wp-json/wp/v2/posts
http://seusite.com/wp-json/wp/v2/comments
http://seusite.com/wp-json/wp/v2/media
```

### WPGraphQL

Agora, se você quer uma parada mais moderna e eficiente, tem o WPGraphQL. É um plugin baseado em GraphQL que permite fazer consultas mais precisas e personalizadas.

![Plugin WpGraphQL no mercado do WP.](https://kinsta.com/wp-content/uploads/2023/11/wpgraphql-plugin.png "Plugin WpGraphQL no mercado do WP.")

![Obtenha dados de artigos do WordPress com o WPGraphQL.](https://kinsta.com/wp-content/uploads/2023/11/testing-graphql-wp.jpg "Obtenha dados de artigos do WordPress com o WPGraphQL.")

Com o WPGraphQL, você tem um único endpoint e pode pedir exatamente os dados que precisa, sem ficar pegando um monte de coisa que não vai usar. Por exemplo:

```graphql
{
  post(id: "123") {
    title
    content
    comments {
      edges {
        node {
          content
        }
      }
    }
  }
}
```

Nesse exemplo, a gente tá pegando o título, conteúdo e comentários de um post específico, tudo numa tacada só!

## As vantagens do WPGraphQL

Galera, deixa eu falar mais sobre o WPGraphQL, porque essa parada é muito massa:

1. Endpoint único pra recuperação precisa de dados: Com o WPGraphQL, você tem um endpoint unificado, tipo `/graphql`, que te permite pegar exatamente os dados que você precisa. É bem diferente da API REST, onde você precisa fazer várias chamadas pra pegar tudo que quer.

2. Consultas direcionadas pra uma recuperação eficiente: Com o GraphQL, você pode criar consultas específicas pro que você precisa. Isso evita que você pegue um monte de dado que não vai usar. Por exemplo:

```graphql
{
  posts {
    title
    date
    author {
      name
    }
  }
}
```

Nessa consulta, a gente tá pegando só o título, a data e o nome do autor dos posts. Nada de informação extra que a gente não vai usar!

3. Vários recursos raiz: No WPGraphQL, você pode consultar vários recursos de uma vez só. Tipo, você pode pegar posts e páginas numa única consulta:

```graphql
{
  posts {
    edges {
      node {
        title
        content
      }
    }
  }

  pages {
    edges {
      node {
        title
        content
      }
    }
  }
}
```

Isso deixa tudo mais rápido e eficiente.

## Qual escolher?

Bom, galera, a escolha entre REST API e WPGraphQL vai depender do que você precisa pro seu projeto. Se quer uma solução já integrada no WordPress, vai de REST API. Se quer algo mais moderno e eficiente, o WPGraphQL pode ser uma boa.

No fim das contas, o importante é escolher a ferramenta que melhor se encaixa no seu fluxo de trabalho e nas metas do projeto. Assim você garante uma integração suave entre o WordPress e o framework de frontend que você escolher.

No meu caso, acabei optando pelo WPGraphQL pra fazer a POC (Proof of Concept) pro nosso cliente N. A ideia era usar o WordPress como backend pra alimentar nosso frontend em Next.js, que a gente escolheu pra ajudar no SEO, que era o grande foco do projeto.

E aí, o que acharam dessa lourada? Já passaram por algo parecido? Conta aí nos comentários! Até a próxima, galera!

Lidando com projetos WordPress quando você não é especialista: WPGraphQL ou REST API para Headless WordPress


## `vs` Questions

---

1. <http://stackoverflow.com/questions/804115> (`rebase` vs `merge`).
2. <https://www.atlassian.com/git/tutorials/merging-vs-rebasing> (`rebase` vs `merge`)
3. <https://www.atlassian.com/git/tutorials/undoing-changes/> (`reset` vs `checkout` vs `revert`)
4. <http://stackoverflow.com/questions/2221658> (HEAD^ vs HEAD~) (See `git rev-parse`)
5. <http://stackoverflow.com/questions/292357> (`pull` vs `fetch`)
6. <http://stackoverflow.com/questions/39651> (`stash` vs `branch`)
7. <http://stackoverflow.com/questions/8358035> (`reset` vs `checkout` vs `revert`)
8. <http://stackoverflow.com/questions/5798930> (`git reset` vs `git rm --cached`)

## GENERAL QUESTIONS

---

1. http://stackoverflow.com/questions/5788037 (Recover from `git reset --hard`).
2. http://stackoverflow.com/questions/1146973/ (Revert all local changes to previous state)
3. http://effectif.com/git/recovering-lost-git-commits (Recovering lost commit)
4. https://stackoverflow.com/questions/79165 (Migrating from SVN)
5. https://davidwalsh.name/squash-commits-git (Combining multiple commits into one using `git rebase`).
6. https://stackoverflow.com/questions/1425892 (Merging two git repo)

## WEBSITES REFERENCE

---

1. http://gitready.com/ (Git Tips and Tricks with explanation)
2. https://github.com/git-tips/tips (Repo for most common git tips)
3. http://gitimmersion.com/ (Small Online Book)
4. http://think-like-a-git.net/
5. http://www.ohshitgit.com (Take a look)
6. https://github.com/nvie/gitflow (Alternative branch model for git.)
7. https://github.com/magit/magit (Git GUI for Emacs).

## FAST GIT REFERENCE

---

1. First download the cheetsheat from official: http://git-scm.com
2. For starters and intermediate, focus on only these commands:

   - Configuring : `config, help`.
   - Creating : `init, clone`.
   - Make Changes: `status, diff, add, commit, reset, rm, mv (not important)`.
   - Branching & Merging: `branch, checkout, merge, stash`
   - Review History: `log, tag, diff, show`
   - Update and Publish: `fetch, pull, push, remote`.
   - Very Imp: `reflog` . http://effectif.com/git/recovering-lost-git-commits

3. Commands that are not in official cheatsheet (and advanced): `revert, apply, cherry-pick, rebase, clean, show-ref, update-ref, ls-files`

   - Debugging Commands: `bisect, blame`.

4. `git stash` is lightweight alternative to `git branch`.
5. Git has three stages:

   - Committed : means data is safely stored in your local database.
   - Modified : means you've changed the file but not committed.
   - Staged : means you've marked a modified file in its current version to go into your next commit snapshot.

6. Workflow of git:

   - Working Directory: holds the actual files
   - Index: Acts as a staging area. That is, snapshot for next commit. Will be done by `git add` command.
   - HEAD : Points to the last commit (and current branch) you've made.

7. Anything that is committed in Git can almost be recovered. However files which are not committed can't be recovered.
8. Description of Update and Fetch Commands:

   - `remote`: it only manage set of track repositories.
   - `fetch`: You can fetch new work from that remote server after cloning. Not similar to `clone`. You can later merge that repo with your existing with `merge` command.
   - `pull`: Automatically fetch and merge newest commit from remote server to local branch. By default, it combines fetch and merge.
   - `push`: This will push to the remote server from local branch.

9. When you do branch switching, files in your working directory will change to match that branch.
10. Using `git reflog` you can get back your destroyed commit (done via `git reset --hard`) using either

    - `git checkout -b newBranchName <shaViaReflog>`
    - `git reset --hard <shaViaReflog>`
      But use it in rare cases, because you reflog keep state via sha and it's hard to see which sha belongs to specific commit.

11. `git cherry-pick` is a low level version of `rebase`.
12. For advanced user who want to explore more, see [gitflow](https://github.com/nvie/gitflow). A Git extensions for creating repo operations using different branch model.

### GIT TIPS AND SHORTCUTS

---

Most used commands are: `init, clone, status, log, add, commit, reset, rm, branch, checkout, merge, stash`

```bash
    ## -- Initializing a new git repository
        $$ git init

    ## -- Useful git log commands
        $$ git log --oneline        ## print short sha in one line
        $$ git log -3               ## show only first 3 commit
        $$ git log --author="John"  ## show commits only by this author


    ## -- Cloning a git repository
    ## The other protocols are: ssh, ftp, file://, http(s):// etc...
        $$ git clone git://github.com/something/foo.git

    ## -- Show the status of file
        $$ git status -s  # in short format

    ## -- Add the file to staging area.
        $$ git add foo.js bar.js   ## `--` is used to seperate files from `add` options.
        $$ git add .    # add all the files

    ## -- Show what have changed since you last commit
        $$ git diff  ## with a `--cached` option, show the changes that will go into the next commit snapshot.

    ## -- Commit the changes after you add the files to staging area
        $$ git commit -m 'with an inline message'

    ## -- Auto-commit and track changes to modified file.
    ## NOTE: The files you've not added doesn't track by commit with `-a` command.
        $$ git commit -a -m 'with an inline message'

    ## -- Ammend last commit (i.e, merge to previous commit)
    ## https://nathanhoad.net/git-amend-your-last-commit
    ## After doing `git add .`
        $$ git commit --amend   # alternate is `git reset --soft HEAD~`.
        ## amend a commit without changing previous message
        $$ git commit --amend --no-edit


    ## -- Unstage file from the index only.  See `git reset` also.
    ## NOTE: `git rm` without `--cached` will simply remove the file from both index and working directory.
        $$ git rm --cached  # exact opposite of git add.

    ## -- Throw away local changes after commit (Use with caution)
        $$ git checkout <file>
        # if the branch name and file name are same, then do this
        $$ git checkout -- <file>
        ## for all changes (it's perfect for time travel on previous commit)
        $$ git checkout -f # or `git reset --hard` (but previous one is more safer because with that you're in detached state.)


    ## Delete a single entry from git reflog. (git reflog is useful as it keeps 2 months history).
        $$ git reflog delete HEAD@{N}    ## `N`: 1,2 etc... or <sha>

    ## Undo the last commit, but keep the history and adds a new history
    ## http://stackoverflow.com/questions/27032850/ (for `git reset` vs `git revert` with image)
        $$ git revert

    ## -- check where HEAD is
        $$ git show-ref

    ## Remove the initial commit (git reset doesn't work here, it works only after second commit)
    ## http://stackoverflow.com/questions/6632191/how-to-revert-initial-git-commit
        $$ git update-ref -d HEAD


    ## Push a specific branch
        $$ git push origin <mylocalbranch>

    ## -- Detailed explaination of `git reset` (all three options). P.S. Use git checkout for time travel.
    ## http://stackoverflow.com/a/6866485/2092405
    ## NOTE: All the below three options remove log, so if you want to get back to previous state, you can pick
    ## <sha> from git reflog and do git reset on this.
    ## Suppose the structure is
         A-B-C
             ↑ (master)
    ## Then, nuke commit C and never see it again. Do this:
        $$ git reset --hard HEAD~1
        ## the result is:
             A-B
               ↑ (master)
       ## To undo this command, use;
           $$ git reset --hard <newShaOfReflog>  ## or (git reset --hard HEAD@{1})

    ## Undo the last commit, but keep your changes in working directory.
    ## It will delete the index the from git log also and show you untracked and unstaged files:
        $$ git reset HEAD~1  ## move the pointer one index back (or git reset --mixed HEAD~1)
        ## the result is:
        A-B-C
          ↑ (master)
        ## To undo this command, use;
            $$ git reset <newShaOfReflog>  ## or (git reset HEAD@{1})

    ## Undo the last commit, but don't touch the index and working directory.
    ## When you do git status, you'll see that the same files are in the index as before.
    ## In fact, right after this command, you could do `git commit` and you'd be redoing the same commit you just had.
        $$ git reset --soft HEAD~1


    ## Add a changed file to old commit (not last commit). I.E., fix up old commit
    http://stackoverflow.com/a/2719659/2092405

    ## merge a specific commit from one branch to another branch.
        ## make sure you're in the branch where you want merge.
        $$ git cherry-pick <commit-id-of-feature-branch>

    ## Merge two specific commit together (using rebase)
    http://stackoverflow.com/questions/2563632/how-can-i-merge-two-commits-into-one

    ## Modify a specific commit in git
    http://stackoverflow.com/questions/1186535/how-to-modify-a-specified-commit-in-git
    ## if you're getting this error. Needs a single revision. See this: http://stackoverflow.com/questions/26174757/
    ## Option: 2
        $$ git checkout <shaToThatCommit>
        $$ touch newfile.txt
        $$ git add .
        $$ git commit --amend --no-edit
        $$ git rebase --onto HEAD <shaToThatCommit> master  ## it will do automatic git checkout to master branch


    ## Branching and Merging
    ## ---------------------
    ## List out all the branches
        $$ git branch
    ## Create a new branch `testing` at your last commit
        $$ git branch testing
    ## Switch to branch
        $$ git checkout testing
    ## Shortcut to create a new branch and checkout
        $$ git checkout -b newbranch
    ## Delete a branch
        $$ git branch -d testing
    ## Merge the <branch> on the current working branch
    ## Merge tip: If you're doing merge say, from `wip` to `live` branch and you've edit `live` branch files
    ## then it will not undo changed file which is what we want.
    ## Also, merge conflict occurs when same file changed in both branch, you merged. You can reverse the merge conflict
    ## with `--abort` option
        $$ git merge testing    ## this will merge `testing` branch onto current (`master`) branch.
    ## checkout arbitrary commits instead of branch
        $$ git checkout HEAD~2
    ## Undo deleted branch
        $$ git reflog    ## to see the hash code of branch before deletion.
        $$ git checkout <hashcodeFromReflog>  ## to restore, and then create the same branch from there.
```

## Git reset vs Git revert

---

**NOTE**: `git revert` is advanced command and it may accidently delete your files, if you haven't committed.
http://stackoverflow.com/questions/8358035/whats-the-difference-between-git-revert-checkout-and-reset

- Basically `git revert` undo changes with new commit history (i.e., introduce a new commit that reverse the specified one) while `git reset` (with `--hard`) **BEWARE**. Any changes to tracked files in the working tree and index are discarded.
- `git reset` (with `--soft`) option doesn't touch the index file nor working tree. In this case, index file is staged but not committed and right after this command you can use `git commit`.
- `git reset` (with `--mixed`) option reset the index but not the working tree. In this case, index file is not staged, so after this command you have to use `git add` and `git commit`.

## Git rm and Git reset

---

`git rm` remove the file from the index (with `--cached` option).
`git reset` is specifically about updating the index, moving the HEAD.
These two options are `equivalent only when we first add a file`. After that with `git reset` you can move the index while with `git rm --cached`, you completly destroy the index.

## Fix a `head detached from` message

---

See: http://stackoverflow.com/questions/10228760/fix-a-git-detached-head
Summary: Basically checkout the branch using `git checkout branchname`

## Relative Refs

---

https://www.atlassian.com/git/tutorials/refs-and-the-reflog/refspecs
The `~` character lets you reach parent commits. For eg: The following display the grandparent of HEAD:
`git show HEAD~2`. The `~` character will always follow the first parent of a merge commit.
If you want to follow different parent, use `^` character
For eg: If HEAD is the merge commit, then following returns the second parent of HEAD:
`git show HEAD^2`
Some examples:

```sh
    # Only list commits that are parent of the second parent of a merge commit
    $$ git log HEAD^2
    # Remove the last 3 commits from the current branch
    $$ git reset HEAD~3
    # Interactively rebase the last 3 commits on the current branch
    $$ git rebase -i HEAD~3
```

## Git `fetch`, `pull`, `push`, `remote`

---

**NOTE: You can't push to non-bare repository if the branches are same on both remote and local server**
By default updating the current branch with non-bare repo is denied. If you're the only user, you can set git config
`git config --bool core.bare true` and then delete all files except `.git` in remote.
http://stackoverflow.com/a/2933656/2092405
Some common git urls:

```sh
    ssh://[user@]host.xz[:port]/path/to/repo.git/
    git://host.xz[:port]/path/to/repo.git/
    http[s]://host.xz[:port]/path/to/repo.git/
    ftp[s]://host.xz[:port]/path/to/repo.git/
    [user@]host.xz:path/to/repo.git/
    /path/to/repo.git/
    file:///path/to/repo.git/
```

`git pull` is basically shorthand for `git fetch` followed by `git merge FETCH_HEAD`
`git fetch`: Downlaod new data and branches from remote repository
`git push`: Push your new branches to remote repository.
`git remote`: Manage (list, add and delete) remote repository aliases.

1. To push local repository to your server

```sh
    ## On your server (create a bare repository)
    $$ git init --bare repo.git
    ## On local
    $$ git remote add origin ssh://server/var/www/frontend.git
    $$ git push origin master
    ## After that, use:
    $$ cd /var/www/; git init; git clone frontend.git

    ## or alternative way without bare repository
    ## switch to different branch locally
    ## and then on your server
    $$ git init
    ## from local repository
    $$ git push ssh://server/path/to/git otherBranch
    ## then merge the otherBranch to master in remote repository

    ## Shortcut without switching repository
    $$ git remote add origin ssh://server/path/to/git
    $$ git push origin master:someOtherBranch       ## this push from master to `someOtherBranch`.
```

##### END


My personal Git cheatsheet with common commands and workflows

My Git Cheatsheet

My git cheatsheet

Em celebração ao 303 Day, vamos explorar a incrível jornada do TB-303, um equipamento que não só revolucionou a música eletrônica, mas também se tornou um símbolo de inovação e resiliência fazendo um paralelo com Desenvolvimento de Software.


![TB-303](https://static.roland.com/promos/global_events/303day/tb-303_tr-606.jpg "TB-303")

Era uma vez, em 1981, em uma terra tecnológica de Osaka, no Japão, uma pequena caixa prateada emergiu dos confins criativos da Roland Corporation. Esta não era uma caixa qualquer; era o TB-303, uma criação destinada a substituir o baixista humano para artistas solitários. Desenhado sob a supervisão do engenhoso Tadao Kikumoto, o TB-303 deveria ser o parceiro perfeito para a máquina de ritmos TR-606, unidos pelo revolucionário DIN Sync.

![Tadao Kikumoto](https://static.roland.com/promos/global_events/303day/tadao-kikumoto-hero.jpg "Tadao Kikumoto")

No entanto, o destino tinha outros planos. A tentativa de emular o baixo elétrico não capturou o coração dos músicos, deixando o TB-303 em uma névoa de incompreensão e desinteresse. Com uma produção que cessou rapidamente, o futuro parecia sombrio para esta caixa de sons estranhos.

**A Virada Inesperada: Chicago, 1985**

![Chicago pionners](https://static.roland.com/promos/global_events/303day/303day_phuture_discover.jpg "Chicago Pioneers")

Mas, como em todas as boas narrativas, um plot twist estava à espreita. Na vibrante cena underground de Chicago, uma tribo de visionários musicais, conhecida como Phuture, descobriu esta máquina abandonada. DJ Pierre, Spanky e Herb J não viam um equipamento falho; viam uma tela em branco para a criatividade. Sem manual e sem regras, começaram a experimentar.

Ao torcer os botões do TB-303, transformaram suas falhas em características, seus bipes em batidas. Aqui, nas profundezas da criatividade, nasceu o Acid House, um som que definiria uma era. Com faixas pioneiras como:

1. "Acid Tracks" de Phuture

[![Watch the video](https://articles.roland.com/wp-content/uploads/2021/02/Acidtrax.jpg)](https://youtu.be/igNBeo3QSqc)

2. ‘I’ve Lost Control’ - Sleezy D

[![Watch the video](https://i.discogs.com/SqhdW3Q1VE0Eqae8QGPrD3NBG-uzbtV8R1ZLBKe-I0s/rs:fit/g:sm/q:90/h:600/w:600/czM6Ly9kaXNjb2dz/LWRhdGFiYXNlLWlt/YWdlcy9SLTE2NTA2/MjktMTIzNDk5NjA0/OC5qcGVn.jpeg)](https://youtu.be/lJnqRCwPeSw)

3. "Can You Feel It" de Mr. Fingers

[![Watch the video](https://i.discogs.com/o0fbDofds6W2j9mPRvWzT39Ycrfkb63P9PP338EbpcQ/rs:fit/g:sm/q:90/h:600/w:599/czM6Ly9kaXNjb2dz/LWRhdGFiYXNlLWlt/YWdlcy9SLTg5NzM2/MDgtMTQ3MjU1OTU2/Mi0xMjczLmpwZWc.jpeg)](https://youtu.be/lYMc4MGA3fE)

O som do TB-303 se tornou sinônimo de uma revolução musical. O TB-303, uma vez um fracasso, agora era a voz de uma nova geração pulsante.

![TB-303 SCHEMATICS](https://static.roland.com/promos/global_events/303day/303day_montage.jpg)

**O Paralelo com o Desenvolvimento de Software**

E aqui, meus amigos, é onde nossa história se cruza com o mundo do desenvolvimento de softwares. O TB-303, em sua essência, reflete a jornada do desenvolvimento de software. Ambos começam com uma intenção clara, mas muitas vezes, é no desvio, na falha, onde a verdadeira inovação é encontrada.

Assim como o TB-303 foi redescoberto e reimaginado, os desenvolvedores frequentemente encontram novas vidas para códigos antigos ou projetos mal entendidos. A flexibilidade, a experimentação e a capacidade de ver além do uso pretendido são qualidades compartilhadas por músicos pioneiros e desenvolvedores de software.

A saga do TB-303 nos ensina que, no coração da inovação, reside a vontade de explorar o desconhecido e redefinir o "fracasso" como um trampolim para o sucesso. No desenvolvimento de software, como na música, a transformação surge não apenas da criação do novo, mas da reinvenção do velho.

Então vamos lembrar da história do TB-303. Que possamos abraçar nossos próprios bipes e falhas por mais estranhos que sejam, pois quem sabe? Talvez estejamos a apenas alguns ajustes de nossa própria revolução.

E assim, a história completa do TB-303, de seu humilde início ao estrelato global, espelha a jornada tumultuada, mas ultimamente triunfante, que muitos desenvolvedores de software enfrentam. Em cada linha de código, como em cada batida do 303, reside a potencial próxima grande virada.

---

Mas a jornada do TB-303 não termina nas pistas de dança dos anos 80; ela se estende até a era digital de hoje, com um renascimento na forma de uma experiência interativa online: o [Roland50.studio](https://roland50.studio).

**Renascimento Digital: Roland50.studio**

No coração deste renascimento está o [Roland50.studio](https://roland50.studio), uma plataforma online criativa que celebra meio século de inovação musical da Roland. Esta plataforma digital é uma homenagem aos dispositivos que moldaram a música como a conhecemos, permitindo que usuários de todo o mundo explorem e interajam com versões virtuais de instrumentos lendários, incluindo, é claro, o icônico TB-303.

![TB-303 IN YOUR BROWSER](https://static.roland.com/promos/global_events/303day/roland_50_studio_303.jpg "TB-303 IN YOUR BROWSER")

A Roland colaborou com o renomado designer de som [Yuri Suzuki](https://www.yurisuzuki.com) para criar uma experiência digital que não apenas emula o som do TB-303, mas também captura o espírito de experimentação que definiu sua história. No Roland50.studio, você pode manipular o TB-303 virtual com o clique de um mouse, torcendo os botões e deslizando os controles deslizantes para criar seu próprio som acid house. É uma ponte entre gerações, conectando a nostalgia dos sons analógicos com a acessibilidade da tecnologia digital.

**O Paralelo com o Desenvolvimento de Software**

Aqui, a história do TB-303 se entrelaça novamente com o desenvolvimento de software. O Roland50.studio é um testemunho do poder da tecnologia moderna para reimaginar o passado, transformando instrumentos físicos em experiências digitais acessíveis. Assim como os desenvolvedores refatoram e melhoram o código antigo para novos usos, o Roland50.studio refatora o TB-303 para a era da internet.

Esta plataforma não é apenas uma ferramenta de criação musical; é uma lição em inovação de software. Mostra como interfaces intuitivas e design centrado no usuário podem tornar a tecnologia avançada acessível a um público mais amplo. Para os desenvolvedores, representa um desafio: como podemos transformar nossos próprios "TB-303s" de software, os projetos esquecidos e mal compreendidos, em algo novo e emocionante para a era digital?

**A Batida Continua**

O Roland50.studio, com seu TB-303 virtual, é uma celebração da inovação contínua. Assim como o TB-303 encontrou uma nova vida nas mãos de DJs e produtores de acid house, agora encontra uma nova expressão na web, inspirando uma nova geração de criadores.

Para os desenvolvedores, a mensagem é clara: a inovação não se trata apenas de criar algo novo, mas também de reimaginar o que já existe. Assim como o TB-303 foi transformado de um fracasso comercial em uma lenda da música eletrônica, os projetos de software podem ser reimaginados para novos propósitos e audiências.

Então, da próxima vez que você visitar o Roland50.studio e brincar com o TB-303 virtual, lembre da jornada deste pequeno sintetizador: de Osaka para o mundo, do esquecimento ao estrelato, e agora, para a nuvem. E lembre, na programação como na música, sempre há espaço para reinvenção e inovação.

\*\*Bônus: Playlist que utilizando o TB-303\*\*

<iframe style="border-radius:12px" src="https://open.spotify.com/embed/playlist/37i9dQZF1DX202yvKb0g9m?utm_source=generator&theme=0" width="100%" height="352" frameBorder="0" allowfullscreen="" allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>

**Links importantes**

- <https://www.roland.com/uk/promos/303day/>
- <https://www.roland.com/uk/products/tb-03/>


Celebrating 303 Day, let's explore the incredible journey of the TB-303, a device that not only revolutionized electronic music but also became a symbol of innovation and resilience, drawing parallels with Software Development

The TB-303 Saga: From Obscurity to Electronic Stardom

A Saga do TB-303: Do Esquecimento ao Estrelato Eletrônico

Hoje, nosso foco está nos atalhos que gosto de chamar de "malicias" de JavaScript, são técnicas que ajudam a deixar seu código mais limpo e eficaz.


![Evil cowboy](https://res.cloudinary.com/lucaos/image/upload/w_1000,ar_16:9,c_fill,g_auto,e_sharpen/v1708976693/lucaoskaique/DALL_E_2024-02-26_16.21.43_-_Create_an_image_of_a_mischievous_devilish_emoji_character_but_with_a_unique_twist__it_s_wearing_a_cowboy_hat._The_character_should_embody_the_playfu.webp "Evil Cowboy")

Salve, galerinha viciada em JavaScript!

Eu sou Lucas Kaique, seu engenheiro de software dedicado, trazendo mais insights de JavaScript. Hoje, nosso foco está nos atalhos que gosto de chamar de "malicias" de JavaScript, são técnicas que ajudam a deixar seu código mais limpo e eficaz.

Vamos explorar exemplos práticos, alternando entre a abordagem padrão do JavaScript e suas contrapartes abreviadas.

Então, sem mais delongas, vamos aprimorar suas habilidades em JavaScript!

### 1. Arrow Functions ou Funções de Flecha:

**Aplicação:** Definições Simplificadas de Funções

**JavaScript Padrão:**

```javascript
function add(a, b) {
  return a + b
}
```

**Forma Simplificada:**

```javascript
const add = (a, b) => a + b
```

### 2. Template Literals:

**Aplicação:** Junção Dinâmica de Strings

**JavaScript Padrão:**

```javascript
const name = "Lucas Kaique"
const greeting = "Olá, " + name + "!"
```

**Forma Simplificada:**

```javascript
const name = "Lucas Kaique"
const greeting = `Olá, ${name}!`
```

### 3. Desestruturação de Arrays:

**Aplicação:** Troca de Valores entre Variáveis

**JavaScript Padrão:**

```javascript
let a = 5
let b = 10

let temp = a
a = b
b = temp
```

**Forma Simplificada:**

```javascript
let a = 5
let b = 10

;[a, b] = [b, a]
```

### 4. Avaliação de Curto-Circuito:

**Aplicação:** Substituição para Valores Não Definidos ou Nulos

**JavaScript Padrão:**

```javascript
const username = getUsernameFromAPI()
const displayName = username ? username : "Anônimo"
```

**Forma Simplificada:**

```javascript
const username = getUsernameFromAPI()
const displayName = username || "Anônimo"
```

### 5. Valores Padrão para Parâmetros:

**Aplicação:** Definindo Valores Iniciais para Parâmetros de Função

**JavaScript Padrão:**

```javascript
function greet(name) {
  name = name || "Visitante"
  return `Olá, ${name}!`
}
```

**Forma Simplificada:**

```javascript
function greet(name = "Visitante") {
  return `Olá, ${name}!`
}
```

### 6. Abreviação de Propriedades de Objetos:

**Aplicação:** Formação de Objetos com Variáveis

**JavaScript Padrão:**

```javascript
const name = "Lucas Kaique"
const age = 30

const person = {
  name: name,
  age: age
}
```

**Forma Simplificada:**

```javascript
const name = "Lucas Kaique"
const age = 30

const person = {
  name,
  age
}
```

### 7. Operador Ternário:

**Aplicação:** Atribuição Condicional

**JavaScript Padrão:**

```javascript
let isAdmin
if (user.role === "admin") {
  isAdmin = true
} else {
  isAdmin = false
}
```

**Forma Simplificada:**

```javascript
const isAdmin = user.role === "admin"
```

**Versão ainda mais curta:**

```javascript
const isAdmin = user.role === "admin" ? true : false
```

### 8. Operador de Coalescência Nula:

**Aplicação:** Definição de Valores Padrão para Variáveis Nulas ou Não Definidas

**JavaScript Padrão:**

```javascript
const fetchUserData = () => {
  return "Lucas Kaique" // altere para null ou undefined para observar o comportamento
}

const data = fetchUserData()
const username = data !== null && data !== undefined ? data : "Visitante"
```

**Forma Simplificada:**

```javascript
const fetchUserData = () => {
  return "Lucas Kaique" // altere para null ou undefined para observar o comportamento
}

const data = fetchUserData()
const username = data ?? "Visitante"
```

### 9. Desestruturação de Objetos:

**Aplicação:** Extração de Propriedades de Objetos

**JavaScript Padrão:**

```javascript
const user = {
  name: "Lucas Kaique",
  age: 30,
  country: "Brasil"
}

const name = user.name
const age = user.age
const country = user.country
```

**Forma Simplificada:**

```javascript
const user = {
  name: "Lucas Kaique",
  age: 30,
  country: "Brasil"
}

const { name, age, country } = user
```

### 10. Operador Spread:

**Aplicação:** União de Arrays ou Objetos

**JavaScript Padrão:**

```javascript
const arr1 = [1, 2, 3]
const arr2 = [4, 5, 6]
const combinedArray = arr1.concat(arr2)
```

**Forma Simplificada:**

```javascript
const arr1 = [1, 2, 3]
const arr2 = [4, 5, 6]
const combinedArray = [...arr1, ...arr2]
```

### 11. Atribuição Lógica OR:

**Aplicação:** Definição de Valor Padrão para Variáveis

**JavaScript Padrão:**

```javascript
let count
if (!count) {
  count = 1
}
```

**Forma Simplificada:**

```javascript
let count
count ||= 1
```

### 12. Avaliação de Curto-Circuito para Chamada de Função:

**Aplicação:** Prevenção de Execução Desnecessária de Função

**JavaScript Padrão:**

```javascript
function fetchData() {
  if (shouldFetchData) {
    return fetchDataFromAPI()
  } else {
    return null
  }
}
```

**Forma Simplificada:**

```javascript
function fetchData() {
  return shouldFetchData && fetchDataFromAPI()
}
```

Cabô!!

Implemente essas formas abreviadas em seu código e observe como suas habilidades em JavaScript se expandem.

Até a proxima.


Today, our focus is on shortcuts that I like to call JavaScript "tricks" - techniques that help make your code cleaner and more effective

Mastering JavaScript Shortcuts 😈

Dominando as malicias do JavaScript 😈

Neste artigo, vou te orientar no processo de publicação de um projeto Next.js no Github Pages


## Neste artigo, vou te orientar no processo de publicação de um projeto Next.js no Github Pages .

Eu trabalho no [Dev em Dobro](https://www.instagram.com/devemdobro/), uma Edtech cuja missão é ajudar devs iniciantes a se sentirem menos perdidos quando começam a aprender programação. Pensando nisso, frequentemente organizamos eventos gratuitos onde ensinamos a criar um site do zero com HTML, CSS e JavaScript. E no final, mostramos como subir seu site para deixá-lo online utilizando o GitHub Pages.

Se você ainda não conhece, o GitHub Pages é uma plataforma de hospedagem gratuita dentro do GitHub que permite aos usuários publicar sites diretamente a partir de um repositório no GitHub. Isso significa que você pode hospedar seu código-fonte no GitHub e transformá-lo em um site acessível para qualquer pessoa na internet. É uma ótima ferramenta para apresentar seus projetos, portfólios ou até mesmo artigos de blog. Além disso, é bastante popular entre os desenvolvedores devido à sua integração com o GitHub e à facilidade de uso.

Muitos alunos tentam sempre fazer deploy de uma aplicação no GitHub Pages mas não sabem realmente como ele funciona. Muitos alunos tentam sempre fazer deploy de uma aplicação no github pages mas não sabe realmente como ele funciona. Eles tentam fazer o deploy e, quando algo dá errado, ficam frustrados, e vem chorar "ah mas não funciona" 😂. Brincadeiras a parte, mas entender o GitHub Pages é o primeiro passo para o sucesso. Lembre que, ele é destinado para arquivos estáticos, e aqui entra o pulo do gato para projetos Next.js: você precisa transformá-los de dinâmicos para estáticos.

Este tutorial vai ser muito massa porque vamos integrar as GitHub Actions com o GitHub Pages. Isso significa que você não vai estar apenas publicando sua aplicação Next.js na internet; você vai estar configurando uma pipeline automática. Uma pipeline é um conjunto de processos e ferramentas automatizados, comumente usado em integração contínua e entrega contínua (CI/CD). Nesse contexto, uma pipeline é um processo que guia o desenvolvimento de software através de um caminho de criação, testes e implantação do código. O objetivo da automação do processo é minimizar erros humanos e manter a consistência até a implantação.

Assim, toda vez que você atualizar seu código no seu repositório GitHub, as GitHub Actions entrarão em cena e farão o deploy do seu projeto direto no GitHub Pages. Prático, né?

### Desvendando o mistério:

- **GitHub Actions**: Imagine ter uma equipe de mini robôs dedicados só pra você, sempre de olho no seu repositório. Quando você faz um push, eles saltam para a ação como pequenos heróis do código, realizando tarefas essenciais – eles podem testar seu código para garantir que tudo está nos trinques, verificar a qualidade para que você mantenha seu padrão ou, especificamente para nosso propósito, fazer o deploy do seu projeto automaticamente.
- **GitHub Pages**: Pense nisso como seu próprio espaço de hospedagem web, cortesia do GitHub. É o local ideal para exibir seus projetos de forma profissional, mostrar ao mundo seu portfólio brilhante ou até mesmo compartilhar seus projetos pessoais e experimentos, tudo isso a partir do conforto do seu repositório GitHub.

Aqui uns links caso tenha interesse em se aprofundar:

- [GitHub Actions](https://github.com/features/actions)
- [GitHub Pages](https://pages.github.com)

### Preparação é chave:

Para gente seguir nessa quest, um pouquinho de bagagem é necessário. Um conhecimento introdutório em React e Next.js vai longe – não precisa ser um mestre lvl 80, apenas entender o básico já é suficiente. E, claro, uma noção fundamental de como o GitHub funciona é crucial, afinal, vai ser onde toda a nossa ação vai acontecer.

### Guia Rápido:

1. **Ative o GitHub Pages**: Vá nas configurações do seu repositório, ache a seção do GitHub Pages e configure para usar as GitHub Actions. Você está basicamente dizendo ao GitHub: "Ei, vou automatizar isso, fique de olho".

   ![GitHub Project Settings](/assets/img/passo1.png "GitHub Project Settings")

   ![GitHub Project Settings – GitHub Pages configuration](/assets/img/passo2.png "GitHub Project Settings – GitHub Pages configuration")

2. **Prepare seu App Next.js**: Como o GitHub Pages prefere conteúdo estático, você vai ajustar seu Next.js para saída de páginas estáticas. Você vai mexer no `next.config.js` para garantir que ele exporte seu projeto como arquivos estáticos. Assim, o GitHub pode exibir seu site sem problemas.

```javascript
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "export", // <=== permite exportações estáticas
  reactStrictMode: true
}

module.exports = nextConfig
```

Agora, após executar a próxima `next build`, Next.js irá gerar uma pasta `out` contendo arquivos estáticos do nosso projeto. Nas próximas etapas, essa vai ser a pasta que nós pegaremos carregaremos no GitHub Pages.

PS: você pode usar [getStaticProps ](https://nextjs.org/docs/pages/building-your-application/data-fetching/get-static-props)e [getStaticPaths](https://nextjs.org/docs/pages/building-your-application/data-fetching/get-static-paths) para gerar arquivos estáticos pro seu projeto.

3. **Corrija Problemas de Caminho**: Seu projeto pode ter problemas com imagens ou estilos quebrados porque o GitHub Pages coloca ele em um subdiretório. Você vai resolver isso definindo um `basePath` no seu `next.config.js`. Isso diz ao seu app: "Ei, não estamos mais no mesmo lugar; estamos nesse novo endereço".

O Github publica páginas em um subcaminho de um domínio e usa o nome do projeto como um subcaminho. Parece confuso, então vamos usar a URL do meu projeto como exemplo:

`https://lucaoskaique.github.io/nextjs-to-github-pages/`

Como você pode ver, o Github atribuiu um subdomínio dedicado para mim chamado lucaoskaique(com meu nome de usuário). Mas o projeto é publicado no subcaminho, que no meu caso é /nextjs-to-github-pages. Infelizmente, isso levará a problemas com imagens e estilos ausentes.

Por padrão, Next.js mapeia todos os ativos estáticos do domínio. Isso significa que o arquivo `favicon.ico` será resolvido para `lucaoskaique.github.io/favicon.ico` em vez de `lucaoskaique.github.io/nextjs-to-github-pages/favicon.icon`.

Para corrigir isso, podemos configurar um prefixo de caminho adicionando basePath dentro do arquivo next.config.js:

```javascript
/** @type {import('next').NextConfig} */
const nextConfig = {
  basePath: "/nextjs-to-github-pages",
  output: "export",
  reactStrictMode: true
}

module.exports = nextConfig
```

No meu caso, é `/nextjs-to-github-pages` ja que meu projeto chama nextjs-to-github-pages. Não esquece de botar o `(/)` no inicio do path.

4. **Configure as GitHub Actions**: Aqui é onde a mágica acontece. Você vai criar duas actions: uma para configurar o Node.js (tipo preparando seu ambiente) e outra para a mágica de publicação (levando seu lindo site estático para o mundo ver).

- Ação de configuração do Node (setup-node action) – Essa ação é responsável por configurar o Node.js e instalar todas as dependências. Ter uma ação autônoma para a configuração do Node.js nos permite reutilizá-la em outras pipelines. Por exemplo, no meu projeto, tenho pipelines que executam linter de código e testes. Provavelmente, você também terá mais de uma ação.
- Ação de publicação (publish action) – Esta ação gerencia o processo de build e publica o projeto Next.js no GitHub Pages toda vez que você der um push na branch main do repositório.

Agora, você pode entender por que é benéfico dividir a implantação em duas ações.

Deixe-me começar explicando a ação de configuração do Node (setup-node action). Se liga no código:

```yaml
# File: .github/workflows/setup-node/action.yml
name: setup-node
description: "Configura Node.js ⚙️ - Cache dependencies ⚡ - Instala dependências 🔧"
runs:
  using: "composite"
  steps:
    - name: Configura Node.js ⚙️
      uses: actions/setup-node@v4
      with:
        node-version: 20

    - name: Cache dependencies ⚡
      id: cache_dependencies
      uses: actions/cache@v3
      with:
        path: node_modules
        key: node-modules-${{ hashFiles('package-lock.json') }}

    - name: Instala dependências 🔧
      shell: bash
      if: steps.cache_dependencies.outputs.cache-hit != 'true'
      run: npm ci
```

Importante: Coloque este arquivo no diretório `.github/workflows/setup-node` do seu projeto. Certifique-se de nomear o arquivo como `action.yml`.

O que este código faz?

- Ele declara uma ação composta. A ação composta permite agrupar múltiplos passos de um workflow em uma única ação, combinando múltiplos comandos de execução em uma única ação reutilizável.
- Ele cria um novo ambiente de build e configura o Node.js 20 lá.
- Ele instala dependências npm e utiliza um mecanismo de cache para acelerar este processo.

Estas são as partes mais importantes da ação de configuração do Node (setup-node action).

Agora, vamos passar para a última ação, que é a publicação (publish).

```yaml
# File: .github/workflows/publish.yml
name: publish-to-github-pages
on:
  push:
    branches:
      - master

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v4

      - name: Configura Node.js ⚙️ - Cache dependencies ⚡ - Instala dependências 🔧
        uses: ./.github/workflows/setup-node

      - name: Configura Pages ⚙️
        uses: actions/configure-pages@v4
        with:
          static_site_generator: next

      - name: Build com Next.js 🏗️
        run: npx next build

      - name: Upload do artefato 📡
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./out

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

    runs-on: ubuntu-latest
    needs: build

    steps:
      - name: Publica no GitHub Pages 🚀
        id: deployment
        uses: actions/deploy-pages@v4
```

Coloque este arquivo no diretório `.github/workflows` do seu projeto. Você pode nomear o arquivo como desejar – eu o chamei de `publish.yml`.

O que este código faz?

- Esta ação é executada quando o código é enviado ou mesclado na branch principal.
- Ela utiliza a ação setup-node para configurar o ambiente.
- A ação tem dois estágios: no primeiro estágio, o aplicativo Next.js é empacotado. No segundo estágio, nós fazemos o upload dos artefatos do primeiro estágio para o GitHub Pages.
- Estes são os aspectos mais importantes da pipeline de implantação. Eu pulei a configuração de permissões e concorrência, pois permanecem inalteradas para todas as implantações.

Agora, sua action está pronta para ser usada.

5. **Faça o Push e Observe**: Depois de fazer essas alterações, quando você fizer o push, as GitHub Actions vão iniciar automaticamente o deploy para o GitHub Pages.

Após fazer o commit e o push das suas mudanças para a branch principal, o GitHub automaticamente iniciará o deploy para o GitHub Pages.

Para inspecionar o processo, navegue até a aba Actions (1 na imagem abaixo), e selecione a ação publish-to-github-pages no menu do lado esquerdo (2). Você verá todas as suas implantações na tela (elas são chamadas de workflows).

![GitHub Actions – Workflows responsáveis pela publicação no GitHub Pages](/assets/img/passo5.png "GitHub Actions – Workflows responsáveis pela publicação no GitHub Pages")

Agora, precisamos selecionar o primeiro desses workflows, e você verá uma implantação em dois estágios. No estágio de deploy, você pode encontrar um link para o seu site no GitHub Pages.

![Workflow do Projeto GitHub – Implantação bem-sucedida](/assets/img/passo6.png "Workflow do Projeto GitHub – Implantação bem-sucedida")

E aí, é só curtir seu projeto rodando liso na web!

## Finalizando

O GitHub Pages pode não ser a solução ideal para sites com tráfego massivo de milhões de acessos. No entanto, representa uma opção incrível para desenvolver seu portfólio ou para a hospedagem de sites de projetos open-source.

Existem diversas alternativas gratuitas disponíveis para hospedagem de sites atualmente. Contudo, quis destacar esta opção específica. O GitHub Pages foi criado por desenvolvedores para desenvolvedores – é possível considerá-lo como o habitat natural de um programador. Acredito que todo dev deveria estar familiarizado com ele.

Espero que este artigo sirva como um incentivo para aprender mais sobre as GitHub Actions. Não hesite em experimentar abordagens diferentes e tentar criar algo próprio. Cada aplicação precisa ser lançada, e veja este artigo apenas como um ponto de partida.


In this article, I will guide you through the process of publishing a Next.js project on GitHub Pages

How to Publish a Next.js Project on GitHub Pages

Como publicar um projeto Next.js no Github Pages 

Hoje e quero compartilhar com vocês 12 dicas super úteis que podem melhorar significativamente suas habilidades de programação e a eficiência do desenvolvimento de projetos


![javascript mental](/assets/img/eok1jcbxeai0xui.jpg "javascript mental")

Salve galera! Sextou hoje e quero compartilhar com vocês 12 dicas super úteis que podem melhorar significativamente suas habilidades de programação e a eficiência do desenvolvimento de projetos. Essas dicas abrangem desde manipulações de strings até a melhoria da segurança do código. Chega mais!!!

1. **Camel Case Superior**: Escreva nomes compostos com a primeira letra de cada palavra em maiúsculo, exceto a primeira. É mais que um estilo; é um padrão que traz clareza ao seu código.

   ```javascript
   function camelize(str) {
     return str.replace(/([a-z]+)/g, (match, group) =>
       group ? group.charAt(0).toUpperCase() + match.slice(1) : ""
     )
   }
   console.log(camelize("ola mundo")) // Saída: olaMundo
   ```

2. **Segmentação de Três Dígitos**: Torne números grandes mais legíveis, aplicando a segmentação a cada três dígitos. Ideal para valores financeiros e grandes contagens.

   ```javascript
   function numFormat(num) {
     return num.toString().replace(/\B(?=(\d{3})+(?!\d))/g, ",")
   }
   console.log(numFormat("123456789")) // Saída: 123,456,789
   ```

3. **Acesso Seguro a Propriedades**: Evite erros ao acessar propriedades indefinidas em objetos com um método à prova de falhas.

   ```javascript
   const a = {}
   const proxy = new Proxy(a, {
     get(target, propKey, receiver) {
       return Reflect.get(target, propKey, receiver) ?? {}
     }
   })
   console.log(proxy.b.c) // Saída: undefined
   ```

4. **Tipo de Dispositivo Móvel**: Identifique rapidamente se o usuário está em um Android, iPhone ou iPad para uma experiência de usuário otimizada.

   ```javascript
   function getBrowserInfo() {
     const userAgent = navigator.userAgent.toLowerCase()
     return {
       isAndroid: Boolean(userAgent.match(/android/gi)),
       isIphone: Boolean(userAgent.match(/iphone|ipod/gi)),
       isIpad: Boolean(userAgent.match(/ipad/gi))
     }
   }
   ```

5. **Simulação de Requisição de Formulário**: Implemente a funcionalidade de exportação de arquivos de maneira simples e eficaz.

   ```javascript
   function exportFunc(url, params) {
     const form = document.createElement("form")
     form.style.display = "none"
     form.action = url
     form.method = "post"
     document.body.appendChild(form)

     for (const key in params) {
       const input = document.createElement("input")
       input.type = "hidden"
       input.name = key
       input.value = params[key]
       form.appendChild(input)
     }
     form.submit()
     form.remove()
   }
   ```

6. **Vinculação de Eventos Universal**: Garanta que seus ouvintes de eventos funcionem em qualquer navegador.

   ```javascript
   function customEventBind(ele, eventType, callBack) {
     if (ele.addEventListener) {
       ele.addEventListener(eventType, callBack, false)
     } else if (ele.attachEvent) {
       ele.attachEvent("on" + eventType, callBack)
     } else {
       ele["on" + eventType] = callBack
     }
   }
   ```

7. **Configuração de Cookies**: Gerencie cookies de forma eficiente com controle total sobre seus atributos.

   ```javascript
   function setCookie({ key, value, expires, path, domain, secure }) {
     let cookieString = `${key}=${encodeURIComponent(value)}`
     if (expires) {
       const expirationDate = new Date()
       expirationDate.setTime(
         expirationDate.getTime() + expires * 24 * 60 * 60 * 1000
       )
       cookieString += `; expires=${expirationDate.toUTCString()}`
     }
     if (path) cookieString += `; path=${path}`
     if (domain) cookieString += `; domain=${domain}`
     if (secure) cookieString += "; secure"
     document.cookie = cookieString
   }
   ```

8. **Informações do Navegador**: Extraia detalhes do navegador do usuário para melhorar a compatibilidade do seu site.

   ```javascript
   function getBrowserInfo() {
     const userAgent = navigator.userAgent;
     const browserRegex = /(Chrome|Firefox|Safari|Opera|Edge|Trident)\[/ ]?(\d+)/;
     const browserMatch = userAgent.match(browserRegex);
     return {
       browserName: browserMatch ? browserMatch\[1] : 'Desconhecido',
       browserVersion: browserMatch ? browserMatch\[2] : 'Desconhecido'
     };
   }
   ```

9. **Informações do Sistema Operacional**: Saiba com qual sistema operacional o usuário está navegando para otimizar sua experiência.

   ```javascript
   function getUserOsInfo() {
     const userAgent = navigator.userAgent
     const osRegex = /((Windows NT)|(Mac OS X)|(Android)|(iOS))\s*([\d._]+)/
     const osMatch = userAgent.match(osRegex)
     return {
       osName: osMatch ? osMatch[1] : "Desconhecido",
       osVersion: osMatch ? osMatch[5] : "Desconhecido"
     }
   }
   ```

10. **Validação de Data**: Garanta que as datas de início e fim sejam coerentes e lógicas.

    ```javascript
    function compareDate(beginDate, endDate) {
      const start = new Date(beginDate)
      const end = new Date(endDate)
      return start <= end
    }
    ```

11. **Parâmetros de URL**: Capte facilmente valores de parâmetros de URLs para análises e funcionalidades personalizadas.

    ```javascript
    function getQueryStringRegExp(name) {
      const reg = new RegExp("(^|&)" + name + "=([^&]*)(&|$)", "i")
      const r = window.location.search.substr(1).match(reg)
      if (r != null) return unescape(r[2])
      return null
    }
    ```

12. **Exportação de Arquivos Excel**: Simplifique a criação e exportação de arquivos Excel com uma função personalizada.

    ```javascript
    function exportExcel(headers, data, fileName = "export.xlsx") {
      // Código simplificado para a criação e exportação do arquivo Excel
    }
    ```

Espero que essas dicas ajudem vocês!!! Até a mais!!!!


Today I want to share with you 12 super useful tips that can significantly improve your programming skills and project development efficiency

12 JavaScript Tips Every Developer Should Know

12 Dicas de JavaScript que Todo Desenvolvedor Deve Conhecer

Sabe quando você começa a codar e só quer que as coisas funcionem? Pois é, mas aí você descobre que rola fazer isso de um jeito bem mais top. Tem três coisas que, se você começar a usar agora, vão dar um up no seu código rapidinho.


![](/assets/img/imagem_2024-02-04_202622872.png "Evoluindo na Programação: Lições de um Full Stack")

### **Evoluindo na Programação: Lições de um Full Stack**

Há quase um ano, entrei numa experiência muito divertida no mundo do desenvolvimento, participando ativamente do Dev em Dobro, ajudando no papel de instrutor e mentor. Durante esse período, não apenas compartilhei conhecimentos e esclareci dúvidas, mas também testemunhei o crescimento impressionante de inúmeros alunos, do zero à competência em desenvolvimento web.

Esta jornada reacendeu reflexões sobre meus próprio inicio na programação. Me lembro dos dias em que, sem uma orientação formal, cada linha de código que funcionava era um motivo de celebrar. Essa abordagem "go horse" no código, embora divertida, muitas vezes me deixava à deriva em um mar de práticas questionáveis e dúvidas horrendas.

Refletindo sobre essa trajetória, identifiquei três princípios fundamentais que teriam acelerado meu progresso e refinado minha abordagem ao desenvolvimento desde o início. São lições que transcenderam minha experiência com desenvolvimento. Aqui estão elas:

#### **1. Escrevendo Código para Humanos**

Na programação, a verdadeira arte eu vejo que é escrever código que seja facilmente compreendido por outros desenvolvedores. No início, muitos escrevem código pensando na máquina, performace e etc, mas a realidade é que nosso público principal são os colegas de equipe que vão ler, entender e modificar esse código. Simplificar a complexidade e priorizar a clareza não é apenas uma questão de cortesia profissional, mas uma habilidade essencial na construção de sistemas robustos e colaborativos.

Esse conceito, embora pareça básico, foi uma verdadeira mudança de paradigma para mim. No início, minha visão de programação era puramente técnica: eu via o código como um meio de instruir o computador, focando em como "falar" com a máquina, todo mundo de todos os cursos e trabalho falavam só sobre performance. Mas, com o tempo, percebi algo fundamental que o código é de dev para dev, não de dev para máquina.

A máquina, no final das contas, vai converte tudo em zeros e uns e não tem a menor preocupação com a legibilidade ou a elegância do código. São os nossos colegas que precisam navegar, entender e, muitas vezes, expandir ou corrigir o que escrevemos.

Vamos ilustrar isso com um exemplo prático: a função `groupBy`.

Primeiro se liga:

```javascript
const groupBy = (arr, groupFn) =>
  arr.reduce(
    (grouped, obj) => ({
      ...grouped,
      [groupFn(obj)]: [...(grouped[groupFn(obj)] || []), obj]
    }),
    {}
  )
```

Aqui, demonstramos que podemos condensar operações complexas em uma única linha. Embora isso possa nos fazer sentir mais experientes, na realidade, torna a compreensão do código muito mais difícil para qualquer pessoa que precise revisá-lo.

Agora, considere esta outra implementação:

```javascript
const groupBy = (arr, groupFn) => {
  const grouped = {}
  for (const obj of arr) {
    const groupName = groupFn(obj)
    if (!grouped[groupName]) {
      grouped[groupName] = []
    }
    grouped[groupName].push(obj)
  }
  return grouped
}
```

Esse código pode ser lido de cima para baixo, e é possível entender instantaneamente o que acontece em cada linha. Ele pode não ter a mesma "elegância" da versão anterior, mas sua legibilidade é imensamente superior. E é justamente isso que valorizamos: um código que qualquer pessoa na equipe possa revisitar no futuro e agradecer pela clareza.

Esse princípio de priorizar a legibilidade não só facilita a manutenção do código como também promove uma cultura de colaboração e aprendizado contínuo entre os desenvolvedores. Portanto, da próxima vez que você se sentar para codar, lembre de que está escrevendo para humanos, não para máquinas.

#### **2. Escondendo Informações Atrás das Cortinas**

Uma das maiores revelações que tive foi a eficácia de abstrair detalhes complexos por trás de funções claras e bem definidas. Isso não apenas melhora a legibilidade do código, mas também sua modularidade. Ao encapsular operações complexas, facilitamos a manutenção e incentivamos a reutilização do código.

Minha passagem pelo Dev em Dobro foi mais do que apenas um período de ensino; foi um lembrete constante do poder da educação contínua e do compartilhamento de conhecimento. Ver desenvolvedores emergentes abraçando esses princípios e aplicando-os em seus projetos reforça a crença de que, independentemente de onde começamos, o crescimento contínuo é sempre possível.

Espero que compartilhando essas lições, possa inspirar outros a refletirem sobre suas práticas de codificação e a buscarem sempre a evolução. Afinal, o desenvolvimento de software é uma jornada sem fim, repleta de aprendizados constantes e oportunidades de melhorar não apenas nossos códigos, mas também a nós mesmos como profissionais e mentores.

Para quem já mexeu com React, os hooks são um exemplo perfeito desse princípio:

```javascript
import React, { useState, useEffect } from "react"

function FriendListItem(props) {
  const [isOnline, setIsOnline] = useState(null)

  useEffect(() => {
    function handleStatusChange(status) {
      setIsOnline(status.isOnline)
    }

    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange)
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange)
    }
  })

  return (
    <li style={{ color: isOnline ? "green" : "black" }}>{props.friend.name}</li>
  )
}
```

Nesse caso, temos um componente que mostra um item de lista com a cor dinâmica baseada no status do amigo. Apesar de funcionar direitinho, esse código esconde dentro dele lógicas que não têm muito a ver com o propósito principal do componente `FriendListItem`.

Se a gente pegar essa lógica e criar um hook customizado chamado `useFriendStatus`, dá para simplificar o componente assim:

```javascript
import React, { useState, useEffect } from "react"

function FriendListItem(props) {
  const isOnline = useFriendStatus(props.friend.id)

  return (
    <li style={{ color: isOnline ? "green" : "black" }}>{props.friend.name}</li>
  )
}
```

Isso traz dois benefícios bem legais:

1. A gente pode reutilizar a lógica do `useFriendStatus` em outros lugares.
2. Simplificamos nosso componente para mostrar apenas o que realmente importa para sua funcionalidade.

Falando de um jeito mais amplo, o princípio de esconder informações é sobre colocar detalhes irrelevantes para trás de funções abstratas. Assim, a gente não precisa se preocupar com os detalhes de implementação dentro da função abstrata - podemos focar mais no que ela faz, ou seja, no nome da função que indica seu propósito.

Dessa forma, o código fica mais limpo, fácil de entender e manter, liberando mais tempo para a gente focar na solução dos problemas em vez de decifrar o que cada pedaço do código está fazendo.

#### **3. “Return Early” em Vez de Usar Coisas Aninhadas**

A ultima dica tem a ver especialmente com lidar com validações em rotas de API, é tentador cair na armadilha das condições aninhadas. O padrão "retorne cedo" simplifica a lógica, evitando a complexidade e melhorando a legibilidade do código. Adotar essa prática não só torna o código mais limpo, mas também facilita sua manutenção a longo prazo.

Veja só como geralmente a coisa começa:

```javascript
export const handler = async (req, res) => {
  if (req.method === "POST" || req.method === "OPTIONS") {
    const email = validateEmail(req.body.email)
    if (email) {
      const user = findUserByEmail(email)
      if (user) {
        return res.status(200).json({ user })
      } else {
        return res.status(404).json({ message: "Usuário não encontrado" })
      }
    } else {
      return res.status(422).json({ message: "Faltou o email" })
    }
  } else {
    return res.status(405).json({ message: "Esse método não rola" })
  }
}
```

Esse código pode não estar super complexo, mas já começa a ficar um pouco enrolado. O grande truque aqui é que, em vez de seguir uma linha reta, parece que a gente tá fazendo zig-zag pra entender o fluxo.

Agora, que tal a gente tentar um jeito diferente de escrever isso, utilizando o que chamamos de "Padrão de Retorno Antecipado"? Esse padrão ajuda a cortar o caminho quando algo não está nos conformes, deixando o fluxo mais lógico e direto.

Olha só como poderia ficar:

```javascript
export const handler = async (req, res) => {
  if (req.method !== "POST" && req.method !== "OPTIONS") {
    return res.status(405).json({ message: "Esse método não rola" })
  }

  const email = validateEmail(req.body.email)
  if (!email) {
    return res.status(422).json({ message: "Faltou o email" })
  }

  const user = findUserByEmail(email)
  if (!user) {
    return res.status(404).json({ message: "Usuário não encontrado" })
  }

  return res.status(200).json({ user })
}
```

Dessa forma, o código fica mais limpo e a gente consegue entender o que tá acontecendo passo a passo, de uma maneira bem mais tranquila. Ao invés de um monte de condicionais aninhados, a gente vai direto ao ponto e trata cada caso separadamente, deixando o caminho livre até chegar no resultado que a gente quer lá no final.

---

E﻿spero que essas dicas tenham sido úteis e que essas pequenas dicas te engrandeçam na sua jornada de estudos


You know when you start coding and just want things to work? Well, there are three things that, if you start using them now, will level up your code quickly

3 Personal Techniques That Transformed My Development Career

3 Técnicas Pessoais Que Transformaram Minha Carreira em Desenvolvimento

Este é um exemplo de como estruturar um post com suporte a múltiplos idiomas usando Decap CMS

# Welcome to the Multilingual Post

This is an example post that demonstrates how the i18n system works.

## Features

- Multi-language support
- Simple single-file structure
- Easy to manage in CMS

## How it works

When you create a post in Decap CMS, you'll see tabs for each configured language.
You can switch between tabs and fill in content for each language.

### Translatable fields

The following fields can be translated:
- Title
- Description
- Body (main content)

### Shared fields

The following fields are shared across all languages:
- Publication date
- Image
- Tags
- Categories
- Main class
- Color

## Conclusion

With this structure, you can easily create multilingual content for your blog!


This is an example of how to structure a post with multi-language support using Decap CMS

Software Engineer, founder, and DJ in my spare time.

O Container Zumbi: o Testcontainers Singleton em Rust Vaza (e Ninguém te Avisa)

TimesFM 2.5 — Modelo de séries temporais da Google, agora open source

Sistema agêntico de produção — Arquitetura de referência com sete camadas

SimWorld — Simule agentes de IA em uma cidade virtual

repowise — Inteligência de codebase em quatro camadas via MCP

Stay up to date

Work