GDevCon-6/Architecting for Testability and Observability: Difference between revisions
Created page with "{{infobox |category=presentation |icon=GDevConButton.png |presentation-conference=GDevCon-6{{!}}GDevCon#6 |presentation-presenter=Niko Naredi-Rainer }} {{presentation |presenters=Niko Naredi-Rainer |youtube-id=OMEeCojyEzc }} Category:GDevCon-6" |
No edit summary |
||
| Line 8: | Line 8: | ||
{{presentation | {{presentation | ||
|presenters=Niko Naredi-Rainer | |presenters=Niko Naredi-Rainer | ||
|abstract=When systems grow, testing and observability often become afterthoughts, expensive to retrofit and harder to enforce. What if we could build them in from the very first line of LabVIEW code? | |||
We start with simple, practical examples and use them to explore patterns for testable design: building abstraction layers, handling multiple devices, and structuring clean DQMH modules. For communication, we avoid messy peer-to-peer links and rigid hierarchies by introducing RabbitMQ as a central message broker. This makes modules easier to test and reason about. To see what’s going on inside the system, we add logging and metrics using OpenTelemetry, Loki, and Grafana — tools that bring visibility without adding complexity. | |||
This talk does not deal with theory or perfect architecture. It’s about what has worked for us in real LabVIEW projects — and how to keep things simple, flexible, and reliable as systems grow. | |||
|youtube-id=OMEeCojyEzc | |youtube-id=OMEeCojyEzc | ||
}} | }} | ||
[[Category:GDevCon-6]] | [[Category:GDevCon-6]] | ||
Latest revision as of 13:49, 5 February 2026
 | |
|---|---|
| Conference | GDevCon#6 |
| Presenters | Niko Naredi-Rainer |
When systems grow, testing and observability often become afterthoughts, expensive to retrofit and harder to enforce. What if we could build them in from the very first line of LabVIEW code?
We start with simple, practical examples and use them to explore patterns for testable design: building abstraction layers, handling multiple devices, and structuring clean DQMH modules. For communication, we avoid messy peer-to-peer links and rigid hierarchies by introducing RabbitMQ as a central message broker. This makes modules easier to test and reason about. To see what’s going on inside the system, we add logging and metrics using OpenTelemetry, Loki, and Grafana — tools that bring visibility without adding complexity.
This talk does not deal with theory or perfect architecture. It’s about what has worked for us in real LabVIEW projects — and how to keep things simple, flexible, and reliable as systems grow.