A Java geek

I noticed some time ago that three Mastodon features had stopped working on my blog. Each of them seemed like a separate problem, but they had the same root cause. In this blog post, I aim to describe these issues and propose a simple solution. Domain verification Mastodon allows you to prove that you own a domain.

A couple of years ago, I wrote that The Builder pattern is a finite state machine!. A state machine consists of states and transitions between them. As a developer, I want to make illegal states unrepresentable, i.e., users of my API can’t create non-existent transitions. My hypothesis is that only a static typing system allows this at compile-time. Dynamic typing systems rely on runtime validation. In this blog post, I will show that it holds true, with a caveat.

Last month, I became aware of GitHub agentic workflows. I read the site carefully, but the use cases weren’t very exciting to me. I tried the continuous documentation It didn’t work out initially, and because of my lack of involvement, I left it as it was. However, I succeeded in another one that I want to describe in this post. With lessons learned here, I managed to make the documentation workflow work!

I like to analyze codebases I start working on, or that I left for months. I ask my coding assistant, case in point, Copilot CLI: 'analyze the following codebase and report to me improvements and possible bugs.' It’s vague enough to leave room for crappy feedback, but also for some interesting insights. I did it last week on a code base. Copilot returned a list of a dozen items. I asked it to create a GitHub issue for each, with the relevant labels, including priority.

Leading your organization to use OpenTelemetry is a challenge. In addition to all the usual project hurdles, you’ll face one of these two situations: convince your teams to use OpenTelemetry, or convince them to move from the telemetry tool they are already using to OpenTelemetry. Most people don’t want to change. You’ll need lots of effort and baby steps. My tip is the following: the fewer the changes, the higher your chances of success.

I don’t think it’s necessary to introduce Gregor Hohpe. I’m a big fan, having read Enterprise Integration Patterns, and I’ve recommended the book ever since. When I spoke at the Software Architecture Gathering in 2024, I was fortunate enough to meet him and purchase this book. I’m the happy owner of a signed copy. Modern architects don’t try to be the smartest people in the room–they make everyone else smarter.