O que começou como “deve ser a senha errada” virou uma investigação de várias horas que passou por DHCP, DNS, IPv6 e terminou com a descoberta de que meu provedor de internet estava distribuindo um servidor DNS inválido para qualquer dispositivo que dependesse exclusivamente de IPv4.

Esse tipo de problema não é exclusivo do meu roteador nem do meu dispositivo. Ele é comum o suficiente em dispositivos IoT baratos (assistentes de voz, tomadas inteligentes, brinquedos conectados, campainhas, etc.) que achei que valia a pena documentar o processo de debug, porque a causa raiz é quase sempre a mesma: o dispositivo consegue entrar na rede Wi-Fi, mas não consegue resolver nomes de domínio.

O sintoma

A maioria dos dispositivos IoT segue o mesmo fluxo de configuração: escolhemos a rede Wi-Fi, digitamos a senha, e o aparelho tenta se conectar aos servidores do fabricante para finalizar o cadastro. Quando esse processo falha, normalmente aparece uma de duas categorias de erro:

1. Falha ao entrar na rede Wi-Fi — senha errada, rede de 5GHz (a maioria dos dispositivos IoT baratos só suporta 2,4GHz), modo de segurança incompatível (WPA3-only em vez de WPA2), etc.
2. Falha depois de entrar na rede — o dispositivo consegue se associar ao Wi-Fi e obter um IP, mas não consegue “telefonar para casa” e finalizar o cadastro.

O segundo caso é o mais traiçoeiro, porque tudo parece estar funcionando: o dispositivo aparece na lista de clientes conectados do roteador, tem um endereço IP válido, e mesmo assim a configuração falha com uma mensagem genérica.

Por que “outros dispositivos funcionam” não é uma prova de nada

O meu instinto foi testar se o problema era da rede: “meu notebook e meu celular conectam sem problema, então a rede deve estar OK”. Essa suposição é exatamente o que torna esse bug tão difícil de encontrar.

Sistemas operacionais modernos (macOS, iOS, Android, Windows) têm múltiplos mecanismos de fallback para descobrir um servidor DNS válido:

• DHCPv4, o mecanismo clássico, onde o roteador informa um servidor DNS via a opção 6 do DHCP.
• IPv6 Router Advertisements (SLAAC/RDNSS), um mecanismo completamente separado, no qual o roteador anuncia servidores DNS via IPv6, independente do que está configurado no DHCPv4.
• UPnP / TR-064, protocolos que permitem que aplicativos consultem o gateway diretamente sobre a configuração da conexão WAN, incluindo os servidores DNS que o próprio roteador usa.

Um dispositivo IoT barato, por outro lado, normalmente implementa apenas o DHCPv4 clássico. Sem suporte a IPv6, sem UPnP, sem plano B. Se a única informação que ele recebe (a opção 6 do DHCP) estiver quebrada, ele fica sem DNS — mesmo que o resto da sua rede pareça funcionar perfeitamente.

Debugando: descubra o que o DHCP está realmente entregando

Percebi que o primeiro passo real de debug não era “meu notebook consegue navegar”, e sim: o que exatamente o servidor DHCP estava entregando como servidor DNS?

No macOS, rodei:

$ ipconfig getpacket en0

Isso mostra o pacote DHCP bruto recebido pela interface, incluindo todas as opções. Reparei na linha domain_name_server:

options:
Options count is 7
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 192.168.0.1
lease_time (uint32): 0x15180
subnet_mask (ip): 255.255.255.0
router (ip_mult): {192.168.0.1}
domain_name_server (ip_mult): {0.0.0.0}
end (none):

Ali estava o problema: domain_name_server igual a 0.0.0.0. Um endereço IP inválido, que nenhum dispositivo consegue usar para resolver nomes de domínio.

No Ubuntu/Debian, o equivalente (usando o NetworkManager) seria:

$ nmcli device show wlan0 | grep IP4.DNS

Em seguida, comparei com o que o sistema operacional estava realmente usando para resolver nomes — que pode ser diferente do que veio pelo DHCP, exatamente por causa dos mecanismos de fallback mencionados acima. No macOS:

$ scutil --dns | grep -A5 "resolver #1"

O resultado revelou o resto da história:

resolver #1
  nameserver[0] : 2804:14d:1:0:181:213:132:2
  nameserver[1] : 2804:14d:1:0:181:213:132:3
  if_index : 15 (en0)
  flags    : Request A records, Request AAAA records

Servidores DNS válidos — só que via IPv6, completamente diferentes (e desconectados) do que veio pelo DHCPv4. Meu notebook nunca “sentiu” o problema porque, na prática, ele ignorou o DHCPv4 quebrado e usou os servidores anunciados via IPv6.

Investigando o roteador

Com a hipótese confirmada (DHCPv4 não entrega DNS válido), o próximo passo foi entender por que. Entrei no painel administrativo do roteador — um ONT Huawei HG8245W5-6T-V2 fornecido pela Claro Brasil — e fui até a configuração do servidor DHCP.

Duas coisas chamaram atenção:

1. O campo de DNS estava em branco.
2. O campo estava desabilitado — não dava para digitar nada ali.

Um pouco mais abaixo, na mesma tela, havia duas opções marcadas como ativas: “Ativar Retransmissão DHCP” e “Ativar Opção 125”.

Pelo que entendi, essa combinação é uma configuração típica de operadoras para cenários de “triple play” (internet + TV + telefone), onde o roteador não atua como um servidor DHCP completo — ele apenas retransmite as requisições para um servidor central da operadora, que deveria responder com todas as opções, incluindo o DNS.

O problema: esse servidor central, por algum motivo (provavelmente uma falha de provisionamento do lado da operadora), não está respondendo com um DNS válido. O roteador sabe qual servidor DNS usar — ele mesmo usa esse servidor para sua própria conexão WAN, e é exatamente isso que aparece anunciado via IPv6 — mas essa informação nunca chega até os dispositivos conectados via DHCPv4, provavelmente, porque o roteador está em modo “retransmissão” esperando por uma resposta que nunca chega corretamente.

Tentei também remover o atributo disabled do campo de DNS pelas ferramentas de desenvolvedor do navegador, preencher um servidor manualmente e salvar. O resultado: o painel administrativo simplesmente me deslogou e ignorou a alteração. Isso é provavelmente alguma proteção no firmware do roteador.

A solução: assumir o controle do DHCP

Se o roteador da operadora não ia entregar um DNS válido — e o campo estava literalmente bloqueado na interface —, a saída que encontrei foi parar de depender do DHCP dele.

A ideia é usar algum equipamento com capacidade de NAT/roteamento real (não um simples repetidor/extensor de Wi-Fi, que apenas faz bridge na mesma rede e portanto herda o mesmo problema) entre o roteador da operadora e a rede doméstica. Na prática, foi isso que fiz:

1. Conectei um extensor de Wi-Fi que eu já tinha em casa (um TP-Link RE305) ao roteador da operadora.
2. Desativei por completo o servidor DHCP do roteador da operadora, para evitar dois servidores DHCP respondendo na mesma rede (uma fonte clássica de instabilidade — DHCP starvation à parte, ter dois servidores DHCP ativos na mesma rede sem coordenação gera respostas conflitantes e endereços IP duplicados).
3. Configurei manualmente o servidor DHCP do extensor com um servidor DNS válido — no meu caso, 8.8.8.8 (Google) e 1.1.1.1 (Cloudflare) — e o gateway apontando para o roteador da operadora, em vez de depender do modo automático (que, por padrão, se desativa sozinho quando detecta outro servidor DHCP na rede).
4. Conectei o dispositivo IoT à rede desse extensor.

Um detalhe que me pegou de surpresa: como o extensor estava conectado via Wi-Fi ao roteador principal (em vez de cabo de rede), ele também precisava conseguir um IP para si mesmo nessa rede para funcionar como ponte. Acabei desativando o DHCP do roteador principal antes de configurar um IP fixo para o extensor, e ele ficou sem conseguir se conectar — um problema de “ovo e galinha” que derrubou minha rede inteira por alguns minutos até eu perceber o que tinha acontecido. Por isso vale um cuidado extra: a faixa de IPs do novo servidor DHCP não pode se sobrepor a nenhum IP estático já em uso na rede — incluindo esse IP estático que o próprio extensor passa a usar para se conectar ao roteador principal.

Como exemplo, a configuração que usei no extensor foi mais ou menos essa:

• IP estático do extensor: 192.168.0.70 (fora da faixa do DHCP, para não haver conflito)
• Faixa de IPs do DHCP: 192.168.0.100 – 192.168.0.200
• Máscara de sub-rede: 255.255.255.0
• Gateway: 192.168.0.1 (o roteador da operadora)
• DNS primário/secundário: 8.8.8.8 / 1.1.1.1

Resumindo o processo que segui

Se alguém estiver enfrentando um dispositivo IoT que “conecta ao Wi-Fi mas não termina a configuração”, esse foi mais ou menos o roteiro que segui:

1. Confirmar a rede e o modo de segurança: 2,4GHz (não 5GHz), WPA2 (não WPA3-only). A maioria dos dispositivos baratos não suporta WPA3 nem 5GHz.
2. Verificar o que o DHCP estava realmente entregando (ipconfig getpacket no macOS, nmcli no Ubuntu/Debian), prestando atenção no servidor DNS.
3. Não confiar no fato de outros dispositivos estarem funcionando — vale checar explicitamente se o servidor DNS ativo no notebook ou celular veio do DHCPv4 ou de outra fonte (IPv6, DNS configurado manualmente, etc.).
4. Olhar a configuração do servidor DHCP no painel do roteador, procurando por menções a “DHCP Relay”, “L2 Relay” ou “Option 125” — sinais de que o roteador foi configurado pela operadora para um cenário de rede corporativa/triple-play, e não para uma rede doméstica simples.
5. Se o campo de DNS estiver vazio ou bloqueado, em vez de insistir pelo lado do roteador da operadora, faz sentido introduzir um equipamento próprio com um servidor DHCP funcional entre o roteador e o resto da rede.
6. Em último caso, vale tentar ligar para o suporte técnico da operadora — ainda não fiz isso, mas pretendo.

Sobre qual DNS usar

Depois de assumir o controle do DHCP, fiquei me perguntando: devo usar o DNS da própria operadora ou um público como Google (8.8.8.8) ou Cloudflare (1.1.1.1)?

Prós de usar DNS público:

• Alta disponibilidade e desempenho consolidados globalmente.
• Políticas de privacidade públicas e auditáveis (especialmente no caso da Cloudflare).
• Evita práticas comuns de operadoras, como injeção de anúncios em páginas de erro ou redirecionamento de domínios não encontrados.
• Te desacopla de qualquer instabilidade futura na infraestrutura da operadora — como a que motivou este post.

Prós de usar o DNS da operadora:

• Latência potencialmente um pouco menor, por estar na mesma rede.
• Possivelmente um roteamento um pouco mais otimizado para CDNs baseadas na localização do seu resolver.

Depois de passar por todo esse processo e ver na prática como essa dependência da infraestrutura de DHCP/DNS da minha operadora pode falhar, minha escolha foi clara: desacoplar dessa dependência e usar DNS público.

Security was everywhere

Almost every talk touched on security. It’s the same pattern we’ve seen with other tech waves: build fast, ship it, deal with the consequences later. With agentic AI a mistake can delete or leak something before anyone notices.

Vibe coding has a vibe hacking problem

Sonya from Snyk talked about the security problems with AI-generated code. She brought up Replit’s AI agent deleting a production database, which most people following this space have already heard about. Her framing was that agentic engineering is the next step after vibe coding, and that engineers relying on AI tools will eventually move from shipping and hoping it works to something more deliberate.

A few things from the talk stood out to me:

Slopsquatting — LLMs sometimes hallucinate package names that don’t exist. Attackers notice this and register those same names, so if you install what the model suggested, you’re running their code instead. It’s a supply chain attack that only exists because of how these models work.

The OpenClaw example got the most reaction from the room. The talk went through Cisco’s analysis of OpenClaw: Cisco’s AI Defense team ran their open-source Skill Scanner against a third-party skill called “What Would Elon Do?” that had climbed to #1 in a community repository. They found nine security issues, two of them critical, and described the skill as functionally malware — it exfiltrated data over the network and used prompt injection to get around safety rules. The lesson is the same one we already know from other supply chains: being popular in a catalog doesn’t mean anyone reviewed it.

A few recommendations came out of this part of the talk:

• Secure the prompt: think about security while writing it, not after
• Keep architecture boundaries: separate environments, agents shouldn’t touch production directly
• Harden the supply chain: require SBOMs, watch for typosquatting and slopsquatting, audit MCP servers before enabling them
• AIBOM: Snyk’s term for an AI Bill of Materials, meant to catch shadow AI usage the same way we track shadow IT
• Turn off --yolo and --trust-all-tools flags in MCP clients — apparently people actually use these

There was also a slide about a mindset shift: review what the agent produces, understand it before shipping, and watch out for the model’s people-pleasing bias — it will agree with you even when you’re wrong.

Resources mentioned: OWASP GenAI, Gartner AI TRiSM.

MCP and prompt injection

Josh, co-founder of Zuplo, talked about MCP gateways and spent part of his talk on something that doesn’t come up much: MCP prompt injection, where a malicious MCP server injects instructions straight into the LLM’s context. Prompt injection from users is a known problem by now; injection coming from the MCP layer itself is newer. CyberArk has a threat analysis of MCP that covers this in more detail.

The architecture he described: MCP client → MCP gateway (discovery, authentication, authorisation, guardrails) → MCP servers. The point of the gateway is to put the checks in one place instead of trusting every server on its own.

What’s hard about implementing MCP servers (Solo.io)

A Solo.io session on implementing, securing, and managing MCP servers covered trust (who’s calling), control (what the agent can do), and audit. It also pointed out how the spec has changed: early versions expected the MCP server to handle authorisation itself, which most teams don’t really want to own. Newer, OAuth-oriented directions treat MCP more like a resource server sitting in front of a separate identity layer — not plug-and-play yet, but a cleaner split of responsibility. Worth checking which spec version you’re actually targeting. The Agentgateway project, part of the Linux Foundation, came up as one place this is being worked on.

Docker’s take on isolation

Oleg from Docker made a fairly simple point: LLMs don’t have a concept of boundaries, data and code look the same to them. That’s the root of why agentic systems are risky.

He also showed real screenshots of agents going wrong, including a chat where the agent admits to deleting a production database during a code freeze.

Docker’s four principles for reducing risk:

1. Isolate components
2. Only use trusted components
3. Remove capabilities you don’t need
4. Split deterministic and non-deterministic paths, and put more controls on the latter

Docker is building a sandboxing feature — isolated VMs with a Docker daemon inside, made specifically to contain agents. I didn’t expect to write the sentence “I watched Docker announce a VM solution”, but here we are. Their MCP horror stories post has the technical breakdown if you want more detail.

Context engineering

Danilo Poccia, AWS Chief Evangelist for EMEA, talked about context pressure. He defined context as everything the model sees when making a decision — system prompts, tool definitions, conversation history — and said quality drops once it fills up.

Some of the techniques he covered:

• Unambiguous parameter names (user_id, not user)
• Domain-specific terminology, since niche language compresses meaning
• Returning the minimum amount of information, and making it semantically meaningful rather than a raw UUID
• Multiple focused agents, each with its own context window
• Multi-agent patterns: agents-as-tools, swarms, meta-agents that spin up sub-agents on demand
• Carrying only the outcome of a sub-task forward, not its internal details
• Deferred or lazy loading of context, which is where agent skills fit in

A good chunk of the talk was AWS product pitches — AgentCore Platform, Strands agents — which is what you’d expect from someone in that role. The underlying ideas about context management hold up regardless of which infrastructure you use. Cedar, the open-source policy language AWS built for fine-grained access control, also came up.

Generative UI

Ruben Casas, from Postman and a Google Developer Expert (his job title is apparently Staff Vibe Engineer), talked about generative UI and described three levels:

• Level 1 — Static components: the agent orchestrates, calls tools, passes data; the client renders pre-built components. ag-ui has an SDK for this
• Level 2 — Declarative UI: the agent generates descriptors that get combined with pre-defined components to produce UI. See json-render.dev
• Level 3 — Generative UI: the agent creates the UI on the fly

His point was that so far we’ve mostly been injecting AI into interfaces, like a sidebar chatbot. The newer pattern goes the other way: injecting UI into the agent, rendering components inside the agent’s own window. First-party apps tend to use ag-ui or a2ui protocols; third-party apps go through MCPs.

He landed on declarative generative UI as the right balance for now — enough flexibility without the interface changing completely on every interaction.

Agent skills

Peder Holdgaard Pedersen from Saxo Bank talked about skills and how they relate to MCP. The main idea is progressive disclosure: give the model context bit by bit instead of dumping everything at once.

The three layers he described:

• agents.md — collapsed context: when to use a skill (frontmatter, ~50 tokens)
• skills.md — expanded context: how to use a skill
• References — context navigation: what resources to use

He was clear that skills are a big prompt injection attack surface, and his recommendation was to host skills as resources on MCP servers instead of on public GitHub, where they’re exposed to supply chain attacks. The experimental MCP skills extension is where this seems to be heading.

Hugging Face showed something similar: a tool called UPskill that runs a skill against multiple models to see how it performs. They warned that we might be heading into skills mania, the same way there was MCP mania about a year ago. Their advice was to only use skills when they genuinely add to the model’s knowledge, not as a way to bolt on everything — what they called the Goldilocks principle.

A few other things

• “From MCP, the S is missing” — a joke from the panel, and not far from the truth right now
• Governance in enterprises — multiple organisations are building MCP servers independently, which leads to overlapping efforts. It’s the microservices story again, except the shared infrastructure needed this time is auth, discovery, logging, guardrails, policy enforcement
• Context degradation in multi-agent systems — as agents pass context between each other, it degrades, and nobody seems to have a clean fix for this yet
• The URL pattern https://domain/mcp is showing up as a convention for exposing MCP endpoints, similar to how /.well-known/ standardised certain discovery endpoints
• Tedix talked about ACP (Agentic Commerce Protocol) and x402 for payments, under the framing of “the backendisation of the internet”

Two packed days overall. Security was the theme that came up most consistently. The spec is still settling, especially around auth, and the tooling for testing, monitoring, and operating MCP systems at scale hasn’t caught up with how much people want to build on it. That gap will probably close eventually, but for now, teams putting agentic systems into production are mostly on their own for this part.

Biases

• 50 Cognitive Biases in the Modern World by Marcus Lu
• Chesterton’s Fence: A Lesson in Second Order Thinking
• Why incompetent people think they’re amazing by David Dunning

Career

• A Hippocratic Oath for Technologists by Mariesa Dale
• Charte d’Ethique de l’Ingénieur par l’IESF
• progression.fyi
• SMART Goals by Indeed Editorial Team

CLI

• Moving efficiently in the CLI by Clément Chastagnol

Coding

• Five Factor Testing by Sarah Mei
• Test Doubles by me
• Workflows of Refactoring by Martin Fowler

Continuous Integration & Delivery

• 6 Best Practices for Continuous Delivery Pipelines by Derik Evangelista & myself

Documentation

• Architectural Decision Records
• README Maturity Model by Lauri Apple
• The Inclusive Naming Initiative
• The documentation system by Danielle Procida

Logging

• Logging v. instrumentation by Peter Bourgon
• What’s in a Good Error Message? by Gunnar Morling
• When life gives you lemons, write better error messages by Jenni Nadler

Meetings

• Platform as a Service team takes even-handed approach to meetings by Dan Carley
• The Silent Meeting Manifesto v1: Making meeting suck a little less by David Gasca

Open Source

• The 5 Types of Open Source Projects by Josh Berkus

Process

• Continuous Delivery checklist template

Scaffolding

• Filesystem Structure of a Go project by Flavio Copes

Source-Control

• Clean .gitignore files by Markus Tacker
• Conventional Commits

Support

• PagerDuty Incident Response

Time Management

• Maker’s Schedule, Manager’s Schedule by Paul Graham
• Pomodoro Technique by Francesco Cirillo

On one hand, companies want to achieve good levels of transparency and alignment. Encouraging communication works towards this goal.

On the other hand, leaders rightfully don’t want to share half-baked opinions or on going strategic conversations to avoid creating noise and distraction. Holding up information, in this context, is probably sensible.

Over the past 10 years or so I’ve been in the business of enterprise software development, I observed over-communicating has become an acceptable pattern. The benefits of sharing information most often outweighs the risks.

But, over-communicating paired with emails being used as the preferred tool to broadcast information is working against the original intent.

To protect their mental health and productivity, people are running away and not towards information. In a colleague words, sometimes it feels like “drinking from the fire-hose”.

And more levels you’ve got in your org chart, more this gets exacerbated (entropy).

Depth VS breadth

In his Maker’s Schedule, Manager’s Schedule article, I believe Paul Graham gives us clues to understand why over-communicating can be counter productive.

To get things done, people in the Individual Contributor (IC) track often need to go in depth on a topic and work at a detail level. This requires loading and keeping a fair amount of context in their heads. From a cognitive perspective, this is demanding and time consuming.

When a person in an IC role also has to go through a reasonable amount of information that’s thrown at them on a daily basis, it can be challenging to spare enough mental cycles (or simply time) to focus on something for a couple of hours straight.

This can be, however, less of an issue for those in the management track. Because of the breadth nature of their work, context switching is arguably less painful.

Emails have been abused

Emails, by design, work like a push system. When you send someone an email you are pushing something onto them. The ball is now in their court.

Until not long ago, I was of the opinion that having a good enough set of mailbox rules was the answer. After changing companies a couple of times and playing different roles, I had to recognise I never came up with something that effectively sorted out my incoming emails. Quite the opposite, I felt I was fighting to maintain an ever growing list of rules. The effort was just not worth it.

This made me realise we should maybe repurpose how we use emails.

Defaulting to a pull system

I am now experimenting with only sending emails if:

• or when action is needed, such as “please fill out this form by” or “make sure you opt-in to X” or “feedback request” or even “can you please send me this doc”.
• either something has a direct impact on people, a team or the company, examples are “you are getting a pay rise” or “we are about to become a public company” or “new rules to get into the office”;

For all the rest, I believe we should default to a pull system. This can be achieved by making information available somewhere, like an internal blog post. People who feel concerned or interested can subscribe and engage with.

At work, before I could connect the dots and articulate this idea, some colleagues had already started writing internal blog posts to share their thoughts. I’ve been enjoying this pattern as I know I can delay or even skip reading them. It depends on how interested I am, how much work or head space I have at the moment.

I am now advocating for people in the org to experiment with this idea. I am approaching this as an experiment as, even tough this looks like a more flexible and less invasive pattern to me, I don’t have data to share at this point.

If you feel like you are seeing a similar pattern, and you ever decide to talk to your team about what should be pushed and what can be pulled, I’d be curious to know more.

Derik and I shared our thoughts around best practices for Continuous Delivery pipelines.

A big thanks to Jennifer and all the organisers for all their hard work, it was a great event.

Also a big thanks to all the communities and people presents at the event, specially those who showed up for our talk 🙂

Daniele argues there are 4 types of documentation, each of one serving a different purpose:

• Discussions
• Reference
• How-to guides
• Tutorials

Tutorial

Tutorials are learning-oriented. A good tutorial is a series of steps that help the reader to learn something by doing.

Daniele goes further suggesting learning is not the most important element but providing the reader an enjoyable experience. When that happens, the reader will want to do it again in the future and learning becomes a by-product of the experience (I wished my school teachers thought that way back in time).

Some characteristics of tutorials are:

• deal with concrete (not abstractions).
• lean by doing,
• sense of achievement,
• repeatability,
• how to get started,

The outcome of a tutorial is to help someone to do something and at this stage it is OK to not fully understand what’s going on.

How-to guide

How-to guides are problem-oriented. It generally contains a sequence of steps that, if followed in order, guide the reader through solving a specific issue.

As tutorials are commonly used by readers at the beginning of their learning journey, they might not have enough knowledge to come up with meaningful questions yet. Once they acquire a better understanding and uncover specific issues, a how-to guide is what they need.

A recipe is an example of a how-go guide as it has a clear goal and describes a sequence of steps to achieve that goal.

Some properties of how-go guides are:

• practical usability.
• sequence of steps,
• focused on a specific issue,

Reference

Reference guides are descriptions of something (like a library, framework or programme) and how to use it. It’s information-oriented.

Hopefully when someone get to the point of reading a reference guide they have a good understanding of the mechanics of the thing in question and how to perform some tasks with it.

Some common properties of reference guides are:

• structure.
• description,
• to the point,

Go docs and programming language documentation in general are a good examples of this.

Discussion

Discussion or explanation are understanding-oriented and offer clarifying background and context on a topic. Books, conference talks, essays are some examples.

Good discussions focus on:

• making connections with other topics, concepts.
• explaining the “why”,
• providing context,

Effective documentation

With these 4 types of documentation, it can be challenging for authors not to mix them together as sometimes boundaries can blur. This leads to documentation debt, which makes things tedious, time consuming and ineffective.

It is often the case different types of documentation need one another, like How-to guides linking to References, or Tutorials referring to Discussions for further background. The key though is stepping across boundaries should be optional, allowing readers to either focus on what they want to achieve or taking a detour.

To go further on this check this guide written by Daniele.

I was particularly impressed by the crowd. It’s been the hugest audience I’ve seen in DevOps meetups in London so far, they’ve got a huge community there.

Big shout out to the organisers Matt Saunders and Marc Cluet and all the participants 🙌

It was our first time at DevOps Underground London and I pretty much envoyed everything. Big shout out the all the participants, Skills Matter for having us and the organisers.

The session was recorded and it is available here.

We’ve given this talk a couple of times and to comfortably live code the whole pipeline and talk about everything we believe it’s important, we need on average 1h30. Although, the organisers did challenge us to give the talk in 30 minutes and… challenge accepted! Overall I think we did a decent job, except that we used some code snipets instead of coding the whole thing and, for some misterious reason, our pipeline went red. In the end we just retriggered it and it went green again 😳

It was my first time talking at Concourse London User Group and I enjoyed it. A big shout to the organisers and participants 🙌

In his book xUnit Test Patterns: Refactoring Test Code, Gerard Meszaros came up with the term test doubles to describe the various types of objects or procedures used to facilitate and support testing:

• Mocks are used to verify behaviour by throwing exceptions or failing when they receive calls that differ from their expectations.
• Spies are stubs that record some information based on how they were called. They are generally used when we need to verify if/how many times a function call has been made.
• Stubs provide predictible responses to the calls made during the test, usually programmed to only respond to calls that happen in the context of the test.
• Fake objects have working implementations, but are not suitable for production, given they might have some implementation shortcuts. In-memory database is a common example.
• Dummy objects are passed around but never used. They are commonly used to fill parameter lists, fill in required properties in other objects, etc.

More on this topic:

• Test double
• Mocks Aren’t Stubs