DEV Community: Felipe 0liveira

Passing Once Isn't Reliable — This Week's Agent Engineering Puts the Harness Before the Model

Felipe 0liveira — Tue, 25 Aug 2026 11:14:24 +0000

This digest covers AI agent developments from 2026-08-18 to 2026-08-25: orchestration patterns, tool/function calling, memory, planning loops, multi-agent coordination, and agent evaluation.

🔥 Highlights

AgentWeave: Routing Before Reasoning for Efficient Function Calling in Tool-Rich Language Models — cuts tool exposure 70%, latency 51%.
One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows — pass@1 success hides a pass@20 collapse.
Spine-Branch Coordination for Multi-agent Computer Use — solves VM state merging across parallel agents.
Introducing LangSmith Tuned Evaluators, starting with Perceived Error — grades 100% of production traffic, cheaply.
The Evolution of the Agent Harness — engineering value shifts as models absorb skills.

arXiv (cs.AI / cs.MA)

AgentWeave: Routing Before Reasoning for Efficient Function Calling in Tool-Rich Language Models — 2026-08-24
Instead of touching the model, AgentWeave filters the candidate tool set before the prompt is even processed. Across 48 tasks under the BFCL protocol it cut tool exposure by roughly 70%, input tokens by 62%, and latency by 51% versus exposing every registered tool. Direct, practical payoff for anyone whose agent is choking on function calling with dozens or hundreds of registered tools.

Spine-Branch Coordination for Multi-agent Computer Use — 2026-08-22
Tackles VM state merging in multi-agent computer-use systems: a "spine" keeps the primary VM's state continuous while parallel "branches" gather information and are discarded afterward, removing the need to reconcile divergent state. On 200 long-horizon tasks it lifted success rate by 6–16.5 points and cut cost per task by 34–70% — relevant for anyone architecting parallelism into computer-use agents.

AutoSaddler: Automatic Harness Optimization with Durable Updates from Agent Execution Traces — 2026-08-24
Optimizes the agent's external harness offline, from execution traces rather than the model: it diagnoses failures, generates structured code patches, and selectively validates them before applying. Gains of 9–10 points across three benchmarks make the case for "deep debugging" and constrained edits over shallow reflection or unrestricted rewrites — a useful pattern for evolving production agents without regressions.

Hugging Face Daily Papers

One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows — 2026-08-20
A sandbox and benchmark (507 policy-governed workflows across retail, hospitality, insurance, banking, and IT support) showing that top models hit 65.36% pass@1 but drop to 25.25% pass@20 — finding one successful trajectory once is not the same as being reliably successful. A strong argument against using single-response signals as a proxy for production reliability.

MobilePA-Bench: Benchmarking Mobile Planner Agents on Complex Real-World Tasks — 2026-08-24
A benchmark for mobile planner agents (212 tools, 13 domains) combining interactive tool use with real runtime constraints: task decomposition with sub-agent delegation, memory/preference use for implicit requests, and invoking packaged skills instead of planning every action from scratch. Leading models degrade sharply under strict tool ordering, permissions, and unexpected runtime errors — a warning sign for anyone building planning agents on rigid tool chains.

Anthropic Engineering Blog

Nothing new published on anthropic.com/engineering in this window — the most recent post there predates 2026-08-18.

LangChain / LangGraph Blog

Introducing LangSmith Tuned Evaluators, starting with Perceived Error — 2026-08-18
A managed evaluation system: post-trained, specialized models from LangChain replace frontier LLMs as "judges," cutting evaluation cost by 82% (per their own benchmark) while holding quality. The first evaluator, "Perceived Error," runs automatically over all production conversations — not just a sample — to detect when the agent got confused or misread the request. Practical value: continuous evaluation of 100% of traffic without building a custom evaluator.

LangSmith Preview Builds: Test agent changes before production — 2026-08-20
Temporary, production-like deployments spun up from a branch or PR, auto-synced on every commit and isolated from the main deployment. Lets teams test prompt, tool, model, or integration changes before merge, with non-technical stakeholders inspecting real traces and agent behavior. Practical value: reduces the risk of behavioral regressions in an agent — not just code regressions — becoming a CI/CD architecture decision for agent teams.

OpenAI News

Nothing technical in this window that fits the theme — the items published between 2026-08-17 and 2026-08-24 were policy/compliance, product, or institutional announcements, not agent orchestration or evaluation content.

Latent Space

The Evolution of the Agent Harness — 2026-08-22
Dan McAteer argues that roughly half of an agent's performance comes from the harness surrounding the model, citing spreads of 52.4 to 76.2 points between different harnesses running the same model. The interesting part: as models absorb via RL the capabilities that today live in the harness, engineering value migrates toward what can't be absorbed — an "attention interface" managing interruptions, autonomous decisions, and human approval flows. Useful for deciding where to invest orchestration-layer effort that won't age out.

The /wayfinder Skill: Navigating the "Fog of War" of Planning — 2026-08-20
Matt Pocock proposes an orchestration framework for projects without a clear endpoint, avoiding full upfront planning. The skill structures work around three concepts — a "map" of decisions already made, typed "tickets" (grilling, prototype, research, task), and "sessions" that split context across threads without blowing the context window. Practical takeaway: a consistent shared vocabulary between human and agent is a prerequisite for planning/execution loops that don't drift into ambiguity.

Frontier Model Cost and Open-Weights Popularity is Driving Demand for Model Routing — 2026-08-18
Mostly a cost/business piece, but it surfaces a relevant orchestration detail: Glean uses its own model (Waldo) to pre-filter and assemble the necessary context before invoking the expensive frontier model, avoiding wasted tokens. A useful "triage before routing" pattern for multi-model pipelines.

Simon Willison

smolmachines / smolvm as a sandbox for untrusted Python & JavaScript — 2026-08-19
Smolvm is a hardware-isolated VM platform for running untrusted Python/JS with granular CPU/RAM limits, no network, and filesystem control, via local offline images. Directly relevant to anyone needing to safely execute the outputs of agent tool-calling or code generation without risking the host.

More than just code review — 2026-08-22
Simon argues that working well with coding agents requires instructing them clearly and verifying changes reliably — but not necessarily via line-by-line review. The practical takeaway is about agent evaluation: teams building with agents need alternative verification strategies (tests, observed behavior) instead of relying solely on exhaustive manual code review.

Quoting Jeremy Morrell — 2026-08-19
Simon quotes Jeremy Morrell's post "Extensible Software in the age of LLMs," which proposes combining a reliable core with LLM-generated dynamic extensions, made viable by modern sandboxing. Relevant to anyone thinking about tool/function calling and runtime capability extension as part of an agent's design.

Through-line

The strongest thread this week is that reliability, not raw capability, is where agent engineering effort is concentrating: Thinkingbox shows pass@1 success collapsing at pass@20, LangSmith's Tuned Evaluators exist to catch that kind of drift across 100% of production traffic, and Simon Willison's point about verification beyond code review makes the same argument from the practitioner side. Layered on top of that is a harness-first mindset — AgentWeave, Spine-Branch Coordination, AutoSaddler, and Latent Space's "Evolution of the Agent Harness" all treat the orchestration layer around the model, not the model itself, as the place where engineering gains are currently available.

What are you seeing in your own agents — reliability collapsing under repeated runs, or holding up? Drop a note in the comments.

Ingest-Time Compilation Takes On Query-Time RAG, and Agentic Retrieval Meets Its Limits

Felipe 0liveira — Mon, 24 Aug 2026 20:15:02 +0000

This digest covers RAG and GraphRAG developments from roughly August 17–24, 2026: new arXiv papers, Hugging Face Daily Papers picks, and posts from the blogs we track.

🔥 Highlights

RAG Deserves an Index: Why Ingest-Time Compilation Beats Query-Time Interpretation — pre-compile claims once, stop re-deriving meaning per query.
LineageRAG — grounds GraphRAG evidence in verbatim source spans, not vibes.
When Failures Propagate: Causal Failure Attribution in Agentic RAG — diagnosis collapses to zero past the first hop.
Temporal Validity on Real Software Histories — RAG serves stale facts over a third of the time.
Secure GraphRAG: Wiring Microsoft Copilot Studio to Neo4j with per-user Okta SSO — per-user access control for enterprise GraphRAG.

arXiv (cs.CL / cs.AI)

RAG Deserves an Index: Why Ingest-Time Compilation Beats Query-Time Interpretation (2026-08-21) — Argues for "ingest-time semantic compilation": pre-computing atomic, provenance-validated claims at index time instead of re-deriving meaning from raw chunks on every query. Compiled claims hit 85.2% correctness on ~2.2k tokens vs. 72.5% on 16.3k tokens for chunk-based RAG. Practical value: a concrete architectural alternative if your pipeline is spending its context budget re-interpreting the same passages over and over.
Cost Scales with Change, Not Corpus Size: Incrementally Maintaining an Evolving Semantic Substrate (2026-08-17) — The engineering companion to the paper above: shows incremental low-rank (SVD) updates to a semantic index are 33.7x cheaper per update than a full rebuild, while tracking the rebuilt index to floating-point precision. Answers the obvious objection to ingest-time compilation ("won't re-indexing kill me on updates?") with a working incremental scheme.
LineageRAG: Harnessing GraphRAG by Constructing Evidence Lineages with Source Grounding (2026-08-17) — Builds explicit "evidence lineages" per query, grounding each hop of graph traversal in a verbatim source span instead of leaving the evidence trail implicit. Beats leading GraphRAG baselines by 3.51 R@5 / 5.96 EM / 5.22 F1 on HotpotQA, 2WikiMultiHopQA, and MuSiQue — useful if your GraphRAG answers are accurate but impossible to audit.
When Is Complex Chunking Worth It? A Multi-Objective Evaluation of Chunking Methods at Scale (2026-08-17) — Evaluates 8 chunking strategies across 2 corpora, 3 embedding models, and multiple corpus sizes on both retrieval quality and operational cost (throughput/latency/memory). Bottom line: complex chunking rarely pays off consistently once you account for cost — good ammunition against over-engineering your chunker.
When Failures Propagate: Causal Failure Attribution in Agentic RAG (2026-08-20) — Introduces AgenticRAG-FP, which injects a certified fault at a specific hop and checks whether post-hoc diagnosis can still find it once the agent's trajectory has changed. Coverage-based diagnosis collapses to 0.00 accuracy beyond hop 1 — a hard warning for anyone shipping "explain why the agent failed" tooling on top of agentic RAG.
VisDocAgentBench: Benchmarking Agents for Visually Rich Document Retrieval (2026-08-18) — A strong static retriever hits 97.5% R@1 on direct queries over visually rich documents but only 2.5% on two-bridge (multi-hop) queries; agentic search recovers most of that loss. Quantifies exactly where the extra cost of agentic retrieval is earned, and where it's wasted.
Temporal Validity on Real Software Histories: Eliminating Stale-Fact Errors in Code-Assistant Memory (2026-08-21) — Validated on 130 real GitHub-issue state transitions: standard RAG has no time model and serves superseded facts 36–38% of the time, even with an LLM reranker in the loop. A deterministic supersession-memory system (MemStrata) drives that down to ~0 at comparable latency — sharp, data-backed illustration of a known RAG failure mode.
Weighted Memory Tree: Remembering What Matters for Long-Horizon LLM Agents (2026-08-21) — A hierarchical memory (tasks/subtasks/actions) with per-memory retention scores and decay, instead of a flat growing transcript. Gains +9.97 points accuracy on GAIA-Text over linear memory while cutting prompt tokens by 32.8% — a practical pruning technique for agents that run long.

Hugging Face Daily Papers

Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence (2026-08-21) — A position paper proposing "Graph Engineering" as the successor to prompt/context/harness engineering: explicit, evolving graph structures coordinating tasks, agents, and system state across multi-agent systems. Worth reading if you think of GraphRAG purely as a retrieval technique — this argues the graph itself becomes the coordination layer for the whole agent system.
EviRank: Structured Relevance Evidence for Multimodal Image Re-ranking (2026-08-21) — Recasts reranking as constraint satisfaction: parses queries into typed criteria (required/forbidden/ignorable) across six semantic slots, then reranks via deterministic rubric scoring plus evidence-grounded listwise comparison. State of the art across five multimodal retrieval benchmarks, and a distilled student model retains 90%+ of teacher quality at much lower cost — relevant if your reranker's failures are hard to explain to stakeholders.
MemTrapBench: Benchmarking Cognitive Traps in LLM Memory Use (2026-08-20) — Shows that even faithfully retrieved, relevant memories can distort reasoning (reasoning fixation, belief distortion): every tested memory strategy in the benchmark underperforms a no-memory baseline, with the best methods still losing more than 10%. Proposes a simple inference-time instruction fix (AdaptiveMem). A useful reality check before you ship an agent-memory feature on the assumption that "more retrieved context is strictly better."

Anthropic Engineering Blog

Nothing relevant this week — no new posts on retrieval, agents, or memory engineering in the window.

LangChain blog

Nothing squarely on-topic this week. LangSmith shipped "Tuned Evaluators" (2026-08-18) for flagging perceived error in agent traces, but it's general agent-observability tooling rather than a retrieval-quality or RAG-specific development.

LlamaIndex blog

How LlamaIndex Uses Temporal to Scale Reliable Document Orchestration (2026-08-17) — Describes migrating their document-processing pipeline from RabbitMQ to Temporal for durable workflow execution at millions-of-pages/day scale, addressing fairness and concurrency in ingestion. It's about ingestion infrastructure rather than retrieval quality, but directly relevant if your RAG pipeline's bottleneck is reliably getting documents indexed in the first place.

Neo4j blog

Secure GraphRAG: Wiring Microsoft Copilot Studio to Neo4j with per-user Okta SSO (2026-08-20) — Walks through wiring Microsoft Copilot Studio to a Neo4j-backed GraphRAG system via a Neo4j MCP server on Cloud Run, forwarding each user's Okta access token so graph queries respect per-user permissions instead of a shared service account. Solves the "confused deputy" problem for agentic GraphRAG in enterprise settings that need row/entity-level access control.
This Week in Neo4j: Agent Memory, MCP, Skills, Cypher and more (2026-08-21) — Roundup pointing to real developer work in-window: Aura instances now ship a built-in MCP server for zero-setup OAuth graph access from clients like Claude Desktop, and skill distillation in Neo4j's Agent Memory Service converts agent memory into portable SKILL packages. Useful as a pointer list if you're evaluating Neo4j's agent-memory tooling specifically.

Simon Willison

ChatGPT search now uses the site: operator at scale (2026-08-20) — Citing GEO-monitoring firm Promptwatch, ChatGPT Search's use of the site: operator jumped from 0.3–0.5% to 16–17% of queries after the GPT-5.6 rollout, alongside a drop in Reddit citations. Simon notes this is likely exposed via a structured search(query, recency, domains) function rather than a raw operator string — a concrete data point on a production LLM system shifting toward explicit domain-restricted retrieval to improve source reliability.

Latent Space

Nothing relevant this week — posts in the window covered agent harness design, behavioral simulation, and model routing economics, none with substantive retrieval or memory-architecture content.

Interconnects

Nothing relevant this week — the one post in the window covered open-model business strategy, not retrieval or evaluation.

Through-line

The strongest thread this week is a shift from treating retrieval as a query-time problem to treating it as an ingest-time and provenance problem: pre-compiled semantic indexes, evidence lineages grounded in verbatim spans, and Neo4j's per-user access wiring all move work and accountability earlier in the pipeline instead of hoping the query-time retriever gets it right. The second thread is a set of sober benchmarks pushing back on assumptions: agentic retrieval only earns its cost on genuinely multi-hop queries, more retrieved memory can actively hurt reasoning, and plain RAG has no notion of time and will confidently hand back superseded facts more than a third of the time. Taken together, it's a good week for treating "retrieval works" as a claim to verify per failure mode, not a property you get for free.

What's your pipeline doing about stale facts or evidence provenance? Drop a comment below.

🚀 SemVer: por que esse `1.2.3` muda sua vida (e seus bugs)

Felipe 0liveira — Sat, 09 Aug 2025 15:50:03 +0000

Você já deve ter visto algo assim no package.json:

"react": "^18.2.0"

E aí surge a dúvida:

“Mas que raios significam esses números? É só o dev mostrando que sabe contar?”

Não, jovem padawan. Isso é Semantic Versioning — o famoso SemVer — e ele é mais importante do que parece.

📦 O formato

SemVer segue o padrão:

MAJOR.MINOR.PATCH

Exemplo: 2.5.1 significa:

MAJOR (2) → Mudanças que quebram compatibilidade (breaking changes).

Tipo quando você atualiza e metade do seu código para de funcionar 😅.
MINOR (5) → Novos recursos, mas compatíveis com a versão anterior.

É como adicionar novas pizzas no cardápio sem tirar as antigas.
PATCH (1) → Correções de bugs e ajustes pequenos.

Aquele “remendinho” que ninguém percebe… até perceber.

💡 Por que importa?

Te ajuda a saber o tamanho da treta antes de atualizar.
Facilita comunicação entre equipes.
Evita “surpresas” no deploy — embora a gente saiba que sempre rola.

⚠️ O cuidado com `^` e `~`

No npm/yarn, esses símbolos definem como a versão pode variar:

^1.2.3 → Pode atualizar MINOR e PATCH, mas não MAJOR.
~1.2.3 → Pode atualizar só o PATCH.

📌 Ou seja: aquele npm install inocente pode te trazer um bug fresquinho se você não prestar atenção.

🎯 Moral da história

Confie no SemVer (mas verifique o changelog).
MAJOR = risco alto
MINOR = recurso novo
PATCH = bug corrigido

E lembre-se: nem todo projeto segue SemVer direito… às vezes, a galera inventa moda. 😏

💬 E aí, você segue SemVer ou só atualiza e reza? Conta aí nos comentários.

Definitivamente pontuando tasks

Felipe 0liveira — Thu, 27 Mar 2025 17:03:50 +0000

Matriz de Complexidade e Incerteza

A Matriz de Complexidade e Incerteza é uma ferramenta visual que ajuda equipes e organizações a compreenderem melhor o grau de dificuldade de um projeto ou iniciativa, levando em consideração dois eixos principais:

Complexidade Técnica: Representa o nível de conhecimento tecnológico disponível na equipe, a dependência de outros times e o domínio sobre as soluções técnicas necessárias.
Incerteza de Negócios: Refere-se ao grau de clareza das regras de negócio envolvidas, o entendimento do problema a ser resolvido e o alinhamento com os objetivos estratégicos.

A combinação desses dois eixos gera uma classificação em diferentes níveis de dificuldade, que vão desde contextos simples (baixa complexidade e baixa incerteza) até cenários altamente desafiadores (alta complexidade e alta incerteza).

Para facilitar a compreensão e comunicação entre times, cada nível de dificuldade é representado por um animal simbólico, que reflete de forma lúdica e intuitiva a situação enfrentada. Além disso, os níveis de dificuldade são numerados com base na sequência de Fibonacci, que ilustra a progressão natural do aumento de esforço e incerteza à medida que os desafios se tornam mais complexos.

1. Cachorro

Pontuação: 1
Complexidade: Baixa
Incerteza: Baixa
Definição:

Conhecemos a tecnologia
Não temos dependência de outros times
Regras de negócio bem definidas
Todos conhecem as regras de negócio

2. Cavalo

Pontuação: 2
Complexidade: Baixa
Incerteza: Média
Definição:

Conhecemos a tecnologia
Não temos dependência de outros times
Regras de negócio não estão claras
Alguém do time conhece as regras de negócio

5. Rinoceronte

Ação: Refinar
Pontuação: 3
Complexidade: Baixa
Incerteza: Alta
Definição:

Conhecemos a tecnologia
Não temos dependência de outros times
Regras de negócio confusas e/ou complexas
Ninguém conhece as regras de negócio

3. Cavalo

Pontuação: 5
Complexidade: Média
Incerteza: Baixa
Definição:

Alguém do time conhece a tecnologia
Temos pouca dependência de outros times
Regras de negócio bem definidas
Todos conhecem as regras de negócio

4. Camelo

Pontuação: 8
Complexidade: Média
Incerteza: Média
Definição:

Alguém do time conhece a tecnologia
Temos pouca dependência de outros times
Regras de negócio não estão claras
Alguém do time conhece as regras de negócio

6. Girafa

Ação: Refinar
Pontuação: 13
Complexidade: Média
Incerteza: Alta
Definição:

Alguém do time conhece a tecnologia
Temos pouca dependência de outros times
Regras de negócio confusas e/ou complexas
Ninguém conhece as regras de negócio

7. Rinoceronte

Ação: Quebrar e Refinar
Pontuação: 21
Complexidade: Alta
Incerteza: Baixa
Definição:

Ninguém do time conhece a tecnologia
Temos dependência de outros times
Regras de negócio bem definidas
Todos conhecem as regras de negócio

8. Girafa

Ação: Quebrar e Refinar
Pontuação: 34
Complexidade: Alta
Incerteza: Média
Definição:

Ninguém do time conhece a tecnologia
Temos dependência de outros times
Regras de negócio não estão claras
Alguém do time conhece as regras de negócio

9. Elefante

Ação: Quebrar e Refinar
Pontuação: 55
Complexidade: Alta
Incerteza: Alta
Definição:

Ninguém do time conhece a tecnologia
Temos dependência de outros times
Regras de negócio confusas e/ou complexas
Ninguém conhece as regras de negócio

Esse artigo foi gerado com o auxilio de uma IA Generativa

Fontes:

Iniciando na área de desenvolvimento (guia prático)

Felipe 0liveira — Mon, 18 Nov 2024 13:38:03 +0000

Entrar na área de desenvolvimento pode parecer desafiador no início. Com termos técnicos, múltiplas linguagens de programação, ferramentas e frameworks surgindo constantemente, é natural sentir-se perdido. No entanto, o desenvolvimento de software é uma carreira repleta de oportunidades, desafios empolgantes e possibilidades de crescimento.

Neste post, vamos compartilhar uma visão prática e acessível para quem está começando na área de desenvolvimento, com base em quase uma década de experiência em desenvolvimento Frontend e Fullstack. Nosso objetivo é ajudar você a entender o que é necessário para iniciar sua jornada, os primeiros passos que você deve dar e como se manter motivado ao longo do caminho.

Mas por onde começar?

Se você está pensando em entrar no mundo do desenvolvimento, o primeiro passo é entender as diferentes áreas dentro dessa carreira. Isso ajuda a decidir onde concentrar seus esforços inicialmente. Vamos explicar de forma prática e clara:

Frontend: A “cara” do software

O Frontend é a parte visível de um site ou aplicação, tudo o que o usuário interage diretamente. É como o “design funcional”, onde se criam botões, menus, animações e layouts bonitos e intuitivos.

O que faz um desenvolvedor Frontend?
Ele transforma designs (em ferramentas como Figma ou Photoshop) em código funcional, usando linguagens como HTML, CSS e JavaScript.

Exemplos práticos:

Criar o botão de “comprar” em uma loja virtual.
Fazer uma página se ajustar automaticamente a telas de celular (responsividade).
Adicionar animações, como imagens que aparecem suavemente ao rolar a página.

Se você gosta de combinar lógica com criatividade, o Frontend pode ser um ótimo ponto de partida.

Backend: O cérebro por trás da aplicação

O Backend é o que acontece “nos bastidores”. Ele cuida de tudo que o usuário não vê, como lógica, banco de dados e servidores.

O que faz um desenvolvedor Backend?
Ele garante que os dados fluam corretamente, que as regras de negócio funcionem e que o sistema seja rápido e seguro. Linguagens como Python, Java, Node.js e PHP são comuns aqui.

Exemplos práticos:

Salvar os dados de um formulário em um banco de dados.
Processar pagamentos em um e-commerce.
Implementar uma lógica para recomendar filmes ou produtos com base no perfil do usuário.

Se você gosta de resolver problemas lógicos e trabalhar com dados, o Backend pode ser o caminho.

Fullstack: O "faz tudo"

Um desenvolvedor Fullstack é como um “canivete suíço” da programação. Ele trabalha tanto no Frontend quanto no Backend, conectando os dois lados.

O que faz um desenvolvedor Fullstack?
Ele entende o suficiente de ambos os mundos para construir um sistema completo, desde a interface até a lógica e o banco de dados.

Exemplos práticos:

Criar um blog do zero: da página inicial ao armazenamento das postagens.
Construir uma aplicação que mostre produtos e permita comprá-los, lidando com o design e o pagamento.

Ser Fullstack é ideal para quem gosta de aprender um pouco de tudo e busca flexibilidade.

Qual escolher primeiro?

Frontend: Se você gosta de design, interação visual e de ver resultados rápidos.
Backend: Se prefere lógica, trabalhar “nos bastidores” e lidar com dados.
Fullstack: Se quer explorar tudo e ter uma visão ampla (ideal para quem não sabe por onde começar).

Independentemente do caminho, o importante é dar o primeiro passo! O próximo tópico trará as ferramentas e linguagens essenciais para cada área. 🚀

JavaScript: O Alicerce da Web e Além

Se existe uma linguagem de programação que todo iniciante deveria considerar, essa linguagem é o JavaScript. Extremamente versátil, o JavaScript (ou simplesmente JS) é uma das tecnologias mais utilizadas no desenvolvimento de software. Ele começou como a “linguagem da web”, mas hoje é muito mais do que isso, sendo uma poderosa ferramenta tanto para Frontend, Backend e até mesmo áreas além do desenvolvimento tradicional.

Por que aprender JavaScript?

Onipresença na Web:
Quase todos os sites que você acessa dependem de JavaScript. Ele é responsável por adicionar dinamismo e interatividade às páginas, como menus, animações e formulários que “respondem” ao usuário.

Versatilidade

Com JavaScript, você pode desenvolver para diferentes plataformas:

Frontend: Criar interfaces visuais com frameworks como React, Vue.js ou Angular.

Backend: Construir servidores robustos usando Node.js.

Aplicativos Mobile: Desenvolver apps para Android e iOS com React Native.

Aplicações Desktop:
Criar softwares multiplataforma com Electron.

Inteligência Artificial e Data Science:
Sim, até áreas como IA estão sendo exploradas com bibliotecas JS, como TensorFlow.js.

Comunidade e Recursos

O JavaScript tem uma comunidade global gigantesca. Isso significa que você encontrará muitos tutoriais, vídeos, fóruns e ferramentas gratuitas para aprender e resolver dúvidas.

Alta Empregabilidade:

JS é uma habilidade essencial para desenvolvedores Frontend e muito valorizada por Fullstack e Backend. Empresas de todos os tamanhos, de startups a gigantes como Google e Facebook, usam JavaScript em seus projetos.

O Potencial do JavaScript

Imagine que você quer construir um sistema completo. O JavaScript permite isso com as seguintes ferramentas:

Frontend: Com frameworks como React, você pode criar interfaces modernas e dinâmicas, como as que vemos em redes sociais ou e-commerces.

Backend: Usando Node.js, é possível criar servidores que processam milhões de solicitações por dia. Exemplo? A Netflix usa Node.js para parte de sua plataforma.

Banco de Dados: O JavaScript trabalha bem com bancos de dados modernos como o MongoDB, que usa a mesma estrutura de objetos que o JS (JSON).

API e Integrações: Você pode construir sistemas que se conectam com outros serviços, como gateways de pagamento, redes sociais ou sistemas internos.

Projetos Criativos: Com bibliotecas como Three.js, você pode criar experiências 3D para a web. Quer fazer jogos? Experimente o Phaser.js.

Começando com JavaScript

Aqui está um plano inicial para explorar o JS:

Aprenda o básico: Entenda variáveis, funções, loops e eventos.
Explore o DOM: Descubra como manipular elementos de uma página web.
Crie pequenos projetos: Um jogo simples, um cronômetro ou uma lista de tarefas.
Avance para frameworks: Experimente React para o Frontend e Node.js para o Backend.
Aprofunde-se com APIs e bancos de dados: Conecte suas aplicações ao mundo real.

O JavaScript é a porta de entrada para muitas áreas do desenvolvimento e continua sendo uma das linguagens mais procuradas no mercado. Nos próximos tópicos, vamos falar sobre ferramentas práticas e dicas para você se aprofundar ainda mais. Seu futuro na tecnologia pode começar aqui!

Chegamos ao final deste guia prático, e espero que você tenha se sentido inspirado(a) e mais preparado(a) para dar o primeiro passo na sua carreira em desenvolvimento. A tecnologia é um campo dinâmico, cheio de desafios e oportunidades, e o mais importante é começar, mesmo que pareça desafiador no início. Cada linha de código escrita é um passo em direção a um futuro cheio de possibilidades.

Seja explorando o Frontend, o Backend ou se aventurando como Fullstack, lembre-se: a curiosidade e a prática constante são suas maiores aliadas. E, como vimos, o JavaScript é uma ferramenta poderosa para iniciar essa jornada, conectando você às várias possibilidades da programação.

Agradeço por dedicar seu tempo à leitura deste post e por confiar nessa visão prática de quem já passou pelos desafios e conquistas dessa área. Agora é a sua vez de brilhar!

👉 Compartilhe suas ideias! Tem dúvidas, quer compartilhar sua experiência ou até mesmo sugerir outros tópicos para explorarmos? Deixe um comentário! Vou adorar saber o que você pensa e ajudar na sua caminhada.

Bem-vindo(a) à área de desenvolvimento! O mundo da tecnologia precisa de pessoas como você. 🌟

Até a próxima...

Autor: Felipe Oliveira

Liberar espaço deletando os node_modules/

Felipe 0liveira — Mon, 17 Aug 2020 13:20:27 +0000

Pra quem não sabe a pastinha node_modules, armazena todos os "modulos" e bibliotecas que usamos em nosso projeto, porém na maioria das vezes nós temos mais de 1 projeto que usam uma mesma dependência, na minha maquina em questão, tenho por volta de 40 repositórios que usam o npm.

Por conta disso, tenho muito espaço sendo utilizado em disco e pra dar uma boa aliviada, uma alternativa super interessante é simplesmente apagar as pastas node_modules de cada projeto.

Para não precisar acessar cada diretório, basta abrir o seu terminal e ir para a pasta do seu workspace e rodar o seguinte comando:

~ $ find . -name node_modules -type d -print0|xargs -0 rm -rf --

Esse comando basicamente é dividido em duas partes, a primeira é responsável por procurar todos os diretórios com o nome node_modules e retornar seu caminho completo para o segundo comando que tem a atribuição de deletar, a partir de um caminho e,

All Done Galera!

Espero ter ajudado <3

Frontend - Testes E2E

Felipe 0liveira — Tue, 14 Apr 2020 19:20:39 +0000

Atualmente, são vários os motivos para implementar testes end-to-end em uma aplicação.

Basicamente, o principal motivo de um teste automatizado é a prevenção de futuros problemas e bugs, que em muitos casos são invisíveis para o desenvolvedor, principalmente em grandes projetos.
Outro cenário bem comum que os testes e2e se aplicam, são as execuções em massa como: cadastro, login, consulta, etc.

Um teste e2e permitirá testar todos os cenários, sendo eles válidos ou inválidos, em muito menos tempo que uma pessoa pode fazer.
Dos frameworks disponibilizados atualmente, um dos mais famosos para JavaScript é o Protractor que, juntamente ao Jasmine, entregará as ferramentas necessárias para cobrir com testes toda a sua aplicação.

O site oficial do Protractor fornece uma ótima documentação que te ajudará a iniciar nesse mundo dos testes.
Se você tem uma dúvida ou até mesmo uma observação, sinta-se à vontade para comentar esse post.

E não se esqueça de aplicar DocSoul!

Sua alma na documentação - DocSoul

Felipe 0liveira — Tue, 14 Apr 2020 19:19:39 +0000

Em minha concepção, é necessário entender que ter “boas práticas” não é como aprender uma nova linguagem e sim aplicar uma vertente de lógica visando um entendimento e manutenção futura de um código.

O mais comum é quando um desenvolvedor precisa alterar uma aplicação que não foi codificada com “boas práticas”, sendo necessário muitas vezes, refatorar e perder tempo com coisas que deveriam ser muito mais simples.

Outra situação, é quando um desenvolvedor tem um projeto em desenvolvimento e decide parar a codificação para continuar futuramente.

Se este desenvolvedor fez seu código utilizando boas práticas e até mesmo fazendo DocSoul, terá um ganho de tempo, simplificando e agilizando seu trabalho.

Nomenclatura de variáveis

É muito importante que você deixe que uma variável seja auto explicativa, ou seja, quando um Dev se deparar com ela, ele saberá exatamente o propósito da mesma.

Por exemplo, ao invés de utilizar:

let d
let elapsed
const ages = arr.map((i) => i.age)

Utilize:

let daysSinceModification
const agesOfUsers = users.map((user) => user.age)

Jamais pense em usar:

let nameString
let theUsers

Quando somente o necessário é o melhor:

let name
let users

Funções

Uma função tem o propósito de nomenclatura muito semelhante ao de uma variável, portanto, deixe sua função nomeada de forma com que o desenvolvedor, ao acessar, saiba exatamente sua finalidade.

Por exemplo, imagine que temos uma função que convida um usuário, utilizando seu e-mail. Nesse caso, poderíamos fazer desta forma (uma das formas mais comuns):

function conv (usuario) { }

Basicamente, a abreviação ‘conv’ no nome da função acima significa ‘convidar’ e o parâmetro é chamado de ‘usuário’ pois identificará este por meio de seu email.
Porém, o ideal seria fazer:

function convidarUsuario (email) { }

Desta maneira, a função tem um nome claro independente de onde for chamada!

Ter boas práticas é somente o primeiro passo para ter organização, qualidade e eficiência em seus projetos. O ideal é conciliar com DocSoul, que vai além das boas práticas, é uma cultura a ser desenvolvida e incentivada, tanto por desenvolvedores quanto pela empresa, deixando sua marca no documento, para que quando um desenvolvedor visualize seu código, além de entender a lógica e suas tomadas de decisões, reconheça e entenda que além da linha de raciocínio desenvolvida para aquele código, tem sua marca registrada.

Valeu pessoal!

[MacOS] Biometria para 'sudo' no terminal

Felipe 0liveira — Wed, 25 Mar 2020 17:04:23 +0000

Por que?

Todos nós sabemos que para utilizar o sudo no terminal precisamos digitar nossa senha de super usuário ou admin. Não seria muito interessante se sempre que precisarmos usar nossa senha, pudessemos usar a biometria do nosso Macbook?

Para quem?

Esse tutorial é válido somente para usuários dos Macbooks com Sensor Biométrico.

Como fazer?

1 - Vamos abrir o arquivo /etc/pam.d/sudo através do terminal utilizando o editor de sua preferência, no meu caso utilizarei o nano, que já vem por padrão instalado no MacOS a partir do comando: sudo nano /etc/pam.d/sudo

2 - Com o arquivo aberto, vamos adicionar uma nova forma de autenticação para ele por meio da linha auth sufficient pam_tid.so que deve ser adicionada na segunda linha do arquivo

3 - Para fechar o arquivo basta pressionar control + x (^X) em seguida digite y para confirmar que quer salvar o arquivo e depois é só apertar return para sobrescrever o arquivo atual.

Obs.: Com tudo feito, não se esqueça de encerrar o terminal para que ele recarregue as configurações de permissão e então você pode validar a alteração com o comando sudo echo hello

É isso pessoal, qualquer coisa é só comentar...

Visual Studio Online - Minhas considerações

Felipe 0liveira — Tue, 05 Nov 2019 08:33:16 +0000

Vejo como um enorme passo para a galera dev, principalmente aqueles que trabalham com múltiplos ambientes e em múltiplos dispositivos.

Já vejo a alta possibilidade de ser produtivo utilizando um tablet, o real desenvolvimento por meio de alguma plataforma mobile parece estar crescendo de uma forma muito concreta.

Segue um dos posts falando sobre o #vsonline

Bora discutir sobre galera...

CSS Buttons - Dopamina

Felipe 0liveira — Mon, 26 Aug 2019 08:39:59 +0000

O que nos precisamos fazer, como desenvolvedores, designers, project owners, etc.

É satisfazer o usuário em cada passo que ele avança dentro da aplicação, sendo desde um login, até uma aprovação.

É claro que existem muitas formas de fazer isso, a questão é que muitas vezes podemos dar esse gostinho de dopamina totalmente satisfatória com simples botões.

Upload buttons

💡Tips: submit, survey, file upload, to shop...

Floating action button (FAB)

💡Tips: quick actions, social media, main menu...

Pre action button

💡Tips: delete, confirm, submit...

Slide dopamine

💡Tips: delete submit, to shop...

Share buttons

Tips: quick actions, social networks, menu...

Comenta aí qual é sua animação favorita.

Espero que tenha gostado 🤘

DEV Community: Felipe 0liveira

Passing Once Isn't Reliable — This Week's Agent Engineering Puts the Harness Before the Model

🔥 Highlights

arXiv (cs.AI / cs.MA)

Hugging Face Daily Papers

Anthropic Engineering Blog

LangChain / LangGraph Blog

OpenAI News

Latent Space

Simon Willison

Through-line

Ingest-Time Compilation Takes On Query-Time RAG, and Agentic Retrieval Meets Its Limits

🔥 Highlights

arXiv (cs.CL / cs.AI)

Hugging Face Daily Papers

Anthropic Engineering Blog

LangChain blog

LlamaIndex blog

Neo4j blog

Simon Willison

Latent Space

Interconnects

Through-line

🚀 SemVer: por que esse `1.2.3` muda sua vida (e seus bugs)

📦 O formato

💡 Por que importa?

⚠️ O cuidado com ^ e ~

🎯 Moral da história

Definitivamente pontuando tasks

Matriz de Complexidade e Incerteza

1. Cachorro

2. Cavalo

5. Rinoceronte

3. Cavalo

4. Camelo

6. Girafa

7. Rinoceronte

8. Girafa

9. Elefante

Iniciando na área de desenvolvimento (guia prático)

Mas por onde começar?

Frontend: A “cara” do software

Backend: O cérebro por trás da aplicação

Fullstack: O "faz tudo"

Qual escolher primeiro?

JavaScript: O Alicerce da Web e Além

O Potencial do JavaScript

Começando com JavaScript

Liberar espaço deletando os node_modules/

Frontend - Testes E2E

Sua alma na documentação - DocSoul

Nomenclatura de variáveis

Funções

[MacOS] Biometria para 'sudo' no terminal

Por que?

Para quem?

Como fazer?

Visual Studio Online - Minhas considerações

CSS Buttons - Dopamina

Upload buttons

Floating action button (FAB)

Pre action button

Slide dopamine

Share buttons

⚠️ O cuidado com `^` e `~`