John Gallagher

Imagine your domain object. So an account has a customer. A customer has some bank details. Bank details is a bad idea, but address maybe. And so we could have these different formats that load nested relationships or not. And obviously, you've got to be careful about the performance problems with that. And so you'll have the exact structure of your domain object in your logs, in your traces.

Imagine your domain object. So an account has a customer. A customer has some bank details. Bank details is a bad idea, but address maybe. And so we could have these different formats that load nested relationships or not. And obviously, you've got to be careful about the performance problems with that. And so you'll have the exact structure of your domain object in your logs, in your traces.

That, for me, is a dream. And then every single time an account is

That, for me, is a dream. And then every single time an account is

is logged it's in the same structure awesome so i know that an account is always going to have an id it's always going to have a whatever other attributes you count a pending status whatever it is and so therefore i can say show me every trace where the account was pending boom yeah i love that idea and uh it does it reminds me a little of the introduction of the uh

is logged it's in the same structure awesome so i know that an account is always going to have an id it's always going to have a whatever other attributes you count a pending status whatever it is and so therefore i can say show me every trace where the account was pending boom yeah i love that idea and uh it does it reminds me a little of the introduction of the uh

And then, I mean, the thing that I think is unbelievably ironic is all I'm talking about is convention over configuration. And is that not why we all got into Rails? I know Ruby is a different thing, but Rails is all about convention over configuration. and the entire area of observability, it strikes me, could do with a massive dollop of convention over configuration.

And then, I mean, the thing that I think is unbelievably ironic is all I'm talking about is convention over configuration. And is that not why we all got into Rails? I know Ruby is a different thing, but Rails is all about convention over configuration. and the entire area of observability, it strikes me, could do with a massive dollop of convention over configuration.

And that's what OpenTelemetry are trying to do. The one last thing, and I know that time is getting on, but one last thing I want to just say on that is the other huge opportunity is adding context to errors. So we have these exception objects in Ruby, and people store strings with them, and it's like,

And that's what OpenTelemetry are trying to do. The one last thing, and I know that time is getting on, but one last thing I want to just say on that is the other huge opportunity is adding context to errors. So we have these exception objects in Ruby, and people store strings with them, and it's like,

what how do you suppose how am i supposed to understand anything from a string and then people try and put ids in the strings and you're like no stop so at work i've made this extremely simple um basically a subclass of standard error where you can attach context so when you create the error you pass in structured context so if our logs are structured surely our errors should be structured as well makes sense right so

what how do you suppose how am i supposed to understand anything from a string and then people try and put ids in the strings and you're like no stop so at work i've made this extremely simple um basically a subclass of standard error where you can attach context so when you create the error you pass in structured context so if our logs are structured surely our errors should be structured as well makes sense right so

You can say, this error happened, and here was the account associated with it when that error happened. And here's a user, and here's this. So it gets attached into the error. And then using Rails' new error handling, rails.error.handle, if you've not used it before, look it up. It's absolutely awesome.

You can say, this error happened, and here was the account associated with it when that error happened. And here's a user, and here's this. So it gets attached into the error. And then using Rails' new error handling, rails.error.handle, if you've not used it before, look it up. It's absolutely awesome.

It's one of my favorite things that they've added to Rails recently, relatively recently in the last few years. And you can... basically have listeners to these events, to these errors, beg your pardon. It will catch the errors and then the context is encapsulated in the error. So you can pass these errors around and then you can do interesting stuff with that context.

It's one of my favorite things that they've added to Rails recently, relatively recently in the last few years. And you can... basically have listeners to these events, to these errors, beg your pardon. It will catch the errors and then the context is encapsulated in the error. So you can pass these errors around and then you can do interesting stuff with that context.

And all I do is pull out all the context and send it straight into the logs. And that has absolutely changed the way I debug. Because whenever there's an error and it has all this rich data, you just look in the rich data and you're like, oh, that was the account. That was the Shopify ID. That was a product ID. I've got it.

And all I do is pull out all the context and send it straight into the logs. And that has absolutely changed the way I debug. Because whenever there's an error and it has all this rich data, you just look in the rich data and you're like, oh, that was the account. That was the Shopify ID. That was a product ID. I've got it.

And then you just look at the ID and your external, oh, right, okay, it's out of sync, whatever it is. It makes life so much easier. So that's something I'm really passionate about as well, having domain objects encapsulated within errors. So we've got structured errors, not just structured logs.

And then you just look at the ID and your external, oh, right, okay, it's out of sync, whatever it is. It makes life so much easier. So that's something I'm really passionate about as well, having domain objects encapsulated within errors. So we've got structured errors, not just structured logs.