[{"content":" Running is the constant, and most of it is unremarkable — an hour before work, in whatever weather Zurich has decided on. I am not chasing a PR pace; the only place I care about going fast is on my board. Everywhere else distance is king. That is rather the point: the interesting number is never any single outing, it is what a decade of mostly ordinary ones adds up to. Which is also the thing you cannot feel and can only measure — unremarkable is invisible until something has been quietly counting it for ten years.\n8,953 km 178,706 m climbed 977 hours 846 activities Distance per year 2026 2026 · Run: 710 km 2026 · Ride: 311 km 2026 · Snowboard: 601 km 2026 · Hike: 34 km 2026 · Swim: 4 km 1,661 km 2025 2025 · Run: 912 km 2025 · Ride: 38 km 2025 · Snowboard: 37 km 2025 · Hike: 94 km 2025 · Cross-country Ski: 17 km 2025 · Swim: 4 km 2025 · Other: 8 km 1,109 km 2024 2024 · Run: 1,064 km 2024 · Ride: 149 km 2024 · Snowboard: 148 km 2024 · Hike: 47 km 2024 · Swim: 2 km 2024 · Other: 3 km 1,413 km 2023 2023 · Run: 1,136 km 2023 · Ride: 135 km 2023 · Snowboard: 0 km 2023 · Hike: 121 km 2023 · Cross-country Ski: 26 km 1,419 km 2022 2022 · Run: 1,120 km 2022 · Ride: 86 km 2022 · Snowboard: 15 km 2022 · Hike: 47 km 2022 · Cross-country Ski: 16 km 2022 · Swim: 2 km 1,286 km 2021 2021 · Run: 619 km 2021 · Ride: 133 km 2021 · Hike: 45 km 2021 · Swim: 2 km 799 km 2020 2020 · Run: 548 km 2020 · Hike: 3 km 552 km 2019 2019 · Run: 77 km 77 km 2017 2017 · Run: 302 km 302 km 2016 2016 · Run: 329 km 2016 · Ride: 6 km 335 km Run Ride Snowboard Hike Cross-country Ski Swim Other Run Distance6,819 km Elevation143,994 m Time767 h Activities701 Ride Distance857 km Elevation9,325 m Time51 h Activities28 Snowboard Distance802 km Elevation119,784 m* Time35 h Activities20 Hike Distance392 km Elevation24,338 m Time100 h Activities53 Cross-country Ski Distance58 km Elevation594 m Time6 h Activities5 Swim Distance13 km Elevation14 m Time6 h Activities22 Other Distance11 km Elevation442 m Time11 h Activities17 Last updated 2026-08-02. Aggregated from a Strava data export; activities recorded on a COROS watch. Metres marked * are lift-served — the watch logs the ride up as climbing — so snowboard elevation is left out of the total. ","permalink":"https://www.dominic.dev/sports/","summary":"Runs, hikes, rides and snowboard days — recorded on a COROS watch, aggregated from a Strava export.","title":"Sports"},{"content":"Write your content here in Markdown.\n","permalink":"https://www.dominic.dev/about/","summary":"\u003cp\u003eWrite your content here in Markdown.\u003c/p\u003e","title":"About Me"},{"content":"At the 14th Ansible Meetup in Zurich, I gave a talk on integrating Ansible and Terraform. The session focused on the challenges of provisioning infrastructure, the strengths of each tool, and how to effectively make them work together.\nThe Core Challenge While Ansible is a powerful configuration managment solution, using it for pure cloud infrastructure provisioning comes with hurdles. It lacks resource dependencies, doesn\u0026rsquo;t maintain an infrastructure state, and its declarative nature means running a \u0026ldquo;check mode\u0026rdquo; on infrastructure that doesn\u0026rsquo;t exist yet will simply fail. (There is an upcoming talk about a terraform plan implementation for Ansible - stay tuned)\nTerraform, on the other hand, is built precisely for this. It maintains state, understands dependencies, and teaches you to treat your infrastructure as replaceable cattle 🐄 rather than pets 🐈. However, using Terraform\u0026rsquo;s provisioners (like local-exec) to handle configuration management should always be a last resort.\nThe Integration The ideal workflow is using Terraform to provision the infrastructure and Ansible to configure the software on top of it. During the talk, I explored the just released Ansible provider for Terraform.\nWhile certain features, like triggering playbooks directly from Terraform, still have some inconsistencies, the provider absolutely shines when it comes to inventory management. By creating ansible_host objects in Terraform, you can use the dynamic inventory plugin to allow Ansible to read directly from the Terraform state file. This eliminates the need for complex filtering and seamlessly hands off the newly created infrastructure to Ansible for the final configuration.\nDemo \u0026amp; Source Code During the session, I walked through a practical example of spinning up disposable Ubuntu virtual machines on AWS, attaching public IPs, and configuring Cloudflare DNS records.\nYou can find the complete code to replicate the setup in the repository:\nDemo Repository on GitLab Watch the Full Video Download Presentation Slides\n","permalink":"https://www.dominic.dev/talks/2023-09-12-integrate-ansible-terraform/","summary":"\u003cp\u003eAt the 14th Ansible Meetup in Zurich, I gave a talk on integrating Ansible and Terraform. The session focused on the challenges of provisioning infrastructure, the strengths of each tool, and how to effectively make them work together.\u003c/p\u003e\n\u003ch2 id=\"the-core-challenge\"\u003eThe Core Challenge\u003c/h2\u003e\n\u003cp\u003eWhile Ansible is a powerful configuration managment solution, using it for pure cloud infrastructure provisioning comes with hurdles. It lacks resource dependencies, doesn\u0026rsquo;t maintain an infrastructure state, and its declarative nature means running a \u0026ldquo;check mode\u0026rdquo; on infrastructure that doesn\u0026rsquo;t exist yet will simply fail. (There is an upcoming talk about a \u003ccode\u003eterraform plan\u003c/code\u003e implementation for Ansible - stay tuned)\u003c/p\u003e","title":"Integrating Ansible \u0026 Terraform"},{"content":"Tracking IPs, networks, servers, and virtual machines manually in Excel and Confluence creates an airgap that prevents seamless automation. I shared our journey to bridge this gap during my talk at the 10th Ansible Meetup in Zurich. As we pushed for wider adoption of configuration management, we realized we needed a robust source of truth inventory, leading us to migrate to Netbox for IPAM and device management. Here is a breakdown of how Netbox and Ansible integrate, how context data is structured, and why we sometimes have to bypass modules to interact directly with the API.\nNetbox: The Source of Truth Netbox is an open-source infrastructure resource modeling application that serves as a unified source of truth. It manages IP address management (IPAM), tracking networks, VRFs, and VLANs. Beyond IPs, it natively maps the physical and virtual world, including equipment racks, device types, virtualization clusters, data circuits, and the specific power or console connections between them.\nIts popularity stems from its robust REST API and its ability to act as a dynamic inventory for configuration management. Using the netbox.netbox.nb_inventory plugin, Ansible can automatically group devices by attributes like device_roles or tags, and filter them (e.g., has_primary_ip: true) directly from the Netbox database.\nDemo \u0026amp; Source Code During the session, I showcased a practical example of how we structured our yaml dataset and the use of ansible.builtin.uri module to interact with Netbox.\nYou can find the complete code to replicate the setup in the repository:\nAnsible Netbox Meetup Repository on GitLab Download Presentation Slides\n","permalink":"https://www.dominic.dev/talks/2021-09-28-wip-ansible-netbox/","summary":"\u003cp\u003eTracking IPs, networks, servers, and virtual machines manually in Excel and Confluence creates an airgap that prevents seamless automation. I shared our journey to bridge this gap during my talk at the 10th Ansible Meetup in Zurich. As we pushed for wider adoption of configuration management, we realized we needed a robust source of truth inventory, leading us to migrate to Netbox for IPAM and device management. Here is a breakdown of how Netbox and Ansible integrate, how context data is structured, and why we sometimes have to bypass modules to interact directly with the API.\u003c/p\u003e","title":"WIP: Ansible and Netbox"},{"content":"Interaction between hardened loadbalancers, reverse proxies and web applications are difficult to test in early stages and therefore often only detected late in pre-prod / integration environments under high load and/or edge cases. Molecule allows complex test scenarios with mixed environments (Container, VM, Cloud) in a fully automated way.\n","permalink":"https://www.dominic.dev/talks/2021-09-14-automated-infrastructure-testing/","summary":"\u003cp\u003eInteraction between hardened loadbalancers, reverse proxies and web applications are difficult to test in early stages and therefore often only detected late in pre-prod / integration environments under high load and/or edge cases. Molecule allows complex test scenarios with mixed environments (Container, VM, Cloud) in a fully automated way.\u003c/p\u003e","title":"Automated Infrastructure Testing with Molecule"}]