Speaker 1: How'd you like to listen to dot net rocks with
no ads? Easy? Become a patron for just five dollars
a month. You get access to a private RSS feed
where all the shows have no ads. Twenty dollars a month,
we'll get you that and a special dot net Rocks
patron mug. Sign up now at Patreon dot dot NetRocks
dot com. Hey, welcome back to dot net rocks. I'm
Carl Franklin and I'm Richard Campbell, and we're here for
your geek out pleasure. Not yet, no official geekout, but
you know we're gonna there coming. We're gonna geek out
with our guests.
Speaker 2: Now. There's so much to talk about. I can't even
tell you. I've been writing and writing and writing and writing.
They're gonna be long. Sorry, they're gonna be long.
Speaker 1: Yeah, I think everybody looks forward to that at the
end of the year. Richard, I certainly do.
Speaker 2: I appreciate that. I told you I've I've made a
new talk just on nuclear power.
Speaker 1: Yeah, there's a lot of new stuff.
Speaker 2: And then suddenly all attack giants are talking about nuclear power.
So everybody wants that talk. And it's a physics talk
like I start with I pull up a periodic table
and talk about the actinides and go through a decay
pattern of you two thirty eight like it's.
Speaker 1: Okay, I'm going to have another sandwich.
Speaker 2: And but you know, it all pulls the story together
and some interesting things happening in the space. But we'll
talk about that on the Energy Geek go yeap.
Speaker 1: And first before we bring on Adam, let's do a
little thing called better no framework awesome?
Speaker 2: All right man? What we got?
Speaker 1: Well, I want you guys to go to Boston dot
Chef's makingwaves dot com.
Speaker 2: Nice. What is this?
Speaker 1: So this is a cruise and it's the same cruise
company that does the rock Boat. I don't know if
you've heard that no, but it's like you know, one
hundred bands, oh all on a cruise and you see
a different one like every different venues and stuff. But anyway,
so this is a cruise from all up in New
England Boston to Portland, Maine and Saint John, New Brunswick.
It's in October October twenty fourth through twenty eight in
twenty twenty five. And if you're a fan of you know,
Food Network and Celebrity chefs like I Am.
Speaker 2: Back when Food Network actually talked about food.
Speaker 1: Alton Brown is going to be on this cruise.
Speaker 2: There you go, that's your ringer right there, right, Yep.
We love Alton Brown. He's our kind of geek.
Speaker 1: And then as the Choi, Anne Burrell, Eric Adjepong, Roco
de Spirito, Alex Gerna Shelley, Mark Murphy, Jeff Morrow, and Andrew Zimmern,
Josh Capon, a couple other people that you may have
or may not have heard of. Gabe Bertaccini, who does
a show called chow House with Alex Cornishelly, it's just
going to be great. And so you know, it's a
cruise you have cooking demonstrations and dinners and food cooked
in person by these people and reading the comments from
last year. Some of them like to be a little
more private than others and they don't really come out
and greet and talk, but others will hang out with
you like the whole time. Wow. So I'm just really
really excited to go on this. I've actually bought a ticket,
so oh you're going, I'm going. So if you want
to go on this cruise with me, just get a ticket.
Speaker 2: Let me know that's really fun.
Speaker 1: So that's what I got. Who's talking to us today, Richard?
Speaker 2: I grabbed a comment Taver Show nineteen twelve, which is
just back in August when we talked to Anita Vam
about demain driven design and events sourcing, which I think
will be somewhat orthogonal to the things you were talking about.
Jaye Debauer had this comedy. He says, I've listened to
every episode since sometime in twenty ten. Wow, so that
would be you know, Got the Morning a thousand episodes easy,
And you guys have had a huge impact on my career.
So thanks. I have a reputation for coming into work
and saying I was listening to dot at rocks And anyway,
onto the real meat. We've been using aka dot net
and event sourcing ideas that I need to talk about
and it's a match made in heaven. All the positive
things that I need to had to say, but wanted
to point out one other benefit that's been very interesting.
When you have an event store and an unexpected question arises,
you can always write a bit of code to reprocess
that event streamer streams to calculate the answer to a
new question. I believe Anita mentioned the time travel or
something like that, the events can always be replayed up
to a desired time and allowing you to view the
state as it was at the time. In my experience,
the business is delighted when you can perform magic tricks
like this. Thanks so much for the great show.
Speaker 1: Fantastic.
Speaker 2: Yeah, no, it's great. It is a great point about
this different way of thinking about software that having event
streams that you can store and replay just gives you
all kinds of possibilities for tackling problems. It's certainly been
something I've used when doing profiling for performance problems, where
the fact that we could replay the workload and make
some alterations replay the workload a n it taught us
a lot. So Jay, thank you so much for your
comment and a copy of music Cobi. It's on its
way to you. And if you'd like a copy of
music code by, I write a comment on the website
at dot at Rocks dot com or on the Facebook
to publish every show there. And if you comment there
and I reading on the show, we'll send you copy
of music Coba.
Speaker 1: Music to Koba of course still cranking and people love it.
And yes, I do plan on coming out with another
track taking next year. Yeah, I'm still tankling.
Speaker 2: That's all of that.
Speaker 1: But as for social media, Richard and I have been
on ex Twitter for a long time. Maybe not for long,
I'm not sure. But you can also Rea Stress on
blue Sky, I'm Carl Franklin dot bsky dot social.
Speaker 2: And I'm rich Campbell dot bsky dot social.
Speaker 1: And also on Masterson I'm at Carl Franklin tech hub
dot social.
Speaker 2: And I'm Rich Campbell at Masterdon dot social.
Speaker 1: Yeah. All right, well send us a toot a teat
a suite or whatever the heck you call it. And
that's another way that you could win some music to
code by Skeat, I think is what they call.
Speaker 2: It's a skeet yep, it's I don't know if that's
a great name, but it is what it is.
Speaker 1: John Skeet can't really take credit for that. That's like
one thing that he can't take credit for. He's done
everything else exactly. Okay, let's bring on Adam. Adam Dimitrik
is the CEO of Adaptec Group and the creator of
event Modeling, with over three decades experience in software development
and architecture. Adam is an expert in event driven systems
and event sourcing. He has been instrumental in advancing these methodologies,
particularly through his work on event modeling, which we'll talk
about today, and that provides a transparent, inclusive and collaborative
approach to system design. Adam is a frequent speaker at
international conferences and has contributed significantly to the responsible, efficient
system design and implementation in software industry. Welcome Adam, and
apologies that you haven't been on this show before.
Speaker 3: No worries, I've been busy, so you know, finally our
paths cross and thank you for having me. What a
wonderful intro to the topic as well.
Speaker 2: We've always been in an adjacent thread to each other,
right often at the same shows. I think we've done
a little drinking together now and again. But yeah, long overdue, Adam.
I apologize. You shouldn't it taken it?
Speaker 3: Yeah, twelve years ago is now? And then yeah, yeah now,
and then yeah as you do.
Speaker 1: Sure.
Speaker 2: Yeah.
Speaker 3: We met. Last time I think was NBC OSLO in
Norway twenty twelve, so I was still giving talks back
then on GET which was kind of fairly new and
in a lot of circles and I think patterns Microsoft
Patterns and Practices, the Seacaarras Journey Book. I was involved
in that project.
Speaker 2: Ye yeah, right.
Speaker 3: Exactly that time, and that was I was really doing
a lot of that good stuff getting that going for
that team, which was really fun and engaging way to
help out with.
Speaker 1: Was before I started looking like heat miser. So that's how.
Speaker 2: Wow, look at the Exploring c QRS and Events Sourcing
book is still on the Microsoft side, included the show notes.
Everyone wants to look at it. It's two years old.
But it's not wrong.
Speaker 3: No, no, it's actually it's one of the first fouries
I think into using Azure. So we have a lot
of clients that use Azure for you know, the different
technologies they are cosmos, et cetera, for storing the event streams,
et cetera. So if you're on a very dot net
focused textac you know, this is what I'm going to
be talking about is highly technology agnostic. It's talking about
being responsible with your information system. So sure, really the
whole kind of background of how our parallel lives kind
of weave in and out.
Speaker 1: Yeah, yeah, So the the comment Richard read was a
pretty good introduction to events sourcing if you don't know
what that is. And the whole idea is that instead
of mutating a field and a table, you add a
new record and whatever changed and who changed it, so
that it does become sort of like a time machine
that you can step back and every record is a state. Essentially.
Speaker 3: Yeah, it's like it's like accounting, but for information. That's
how I like to think of it, because accountants don't
have erasers, as the stereotypical thing goes.
Speaker 1: And so interesting you said accountants, because that was the
first introduction to that that I had back in the nineties.
We were building an accounting module for some software I
was building or helping to build, and that was a requirement,
like you could not modify field, you had to write
a diff Essentially.
Speaker 3: What's interesting about the history of this whole idea of
event sourcing is that many kind of credit event sourcing
to Martin Fowlers areticle in December two thousand and five. However,
if you kind of look at information systems in general,
the approach has really been the way you create information
systems throughout thousands of years. Most of the organizations and
systems that happened before computing were literally record keeping and
you needed those carbon copies to know where the heck
things are people filing cabinets by their desks to you know,
to have the old copies there. So events sourcing is
actually quite natural for human beings.
Speaker 1: And I think I always know, if you think about it,
are you taking the eraser away? You know?
Speaker 2: Yeah, for a good reason, guys, get serious talking. You
go all the way back to writing with quills on clay,
right and Kadian, where you can't erase anything, You've got
to throw it out.
Speaker 1: Yeah.
Speaker 2: And that whole markup system was designed for counting an inventory.
It was an entry only system exactly.
Speaker 1: Wow, Richard, that's awesome. What a way to tie this
back to history. Great, it's so cool.
Speaker 3: I think another problem that people have it's a little
bit different than what they're used to. So I have
to say there's a bit of a baby duck syndrome
at play when people are looking at this way of
working a lot of times. But once you're familiar with
both ways of working, either the mutable state way that
we kind of have forms over data a lot of times,
crowd systems or whatever, and these behavior based ledger based approaches.
One of the simplest things about it is that you
really don't have to think about you know, am I
going to have to follow a whole bunch of relationships
between tables right away? When I have a form and
I press submit, it's like, the only thing I need
to do is just store that that was submitted. It's
almost like the systems thinking boundary and capturing things at
the ingress and the outgress, like and that is your
source of truth. So there's very little subjectivity about it.
When you know that your business requires this information that
user is going to be adding something, it really takes
away that subjective kind of discussion of like how am
I going to design this? And oftentimes in this event way,
the event modeling is not really modeling the events themselves.
It's modeling using the building blocks that the events provide
because they're kind of dictated to you, like the business
says this has to happen at this time, so you
have no choice but to capture that information. The subjective
stuff is left how you interpret it later. But the
other good thing about that is is that you are
not really restricted to one way to abstract that projection.
You're free to really do a lot of different projections
for different purposes, so that same information can be used
in an entirely different way further along in the workflow.
And so there's this natural sort of fanning out into
purpose built abstractions, which really gives a lot of awesome
capabilities for people working on the projects. That's also have
a list of one hundred benefits of this approach, and
one of them is this really good autonomy so that
people don't step on each other's toes and so that
you're free to build the abstraction that fits that particular
step in a workflow one percent. Right, You're not make
one abstraction that tries to make all the different pieces happy,
because you're never going to make everyone happy all the time.
So that's kind of one of the really benefits of that.
Speaker 1: Can we just jump back a little bit and yeah,
I mean you kind of jumped into the benefits of
event modeling without really talking about the fundamentals of what
it is. Oh yeah, sure, so elevator pitch.
Speaker 3: Yeah, event modeling is kind of a I mean, you
guys kind of gave a short kind of intro winter this,
but it's really about having a clear and understandable documentation
of what the system is doing, and it really is
a storyboard for for your system, much like you would
have a storyboard for a movie where you have the
scenes at the top row of what's happening visually, but
at the bottom you have notes about you have notes
about the plots to make sure that the movie still
makes sense. So you need to have both, or you
end up with water World. You know, if it looks
really good, you don't want you don't want a water World.
So that's and vice versa, right, I mean you can
have the really you know, a really good story and
you hear about this an excellent book with a horrible
movie adaptation, right, so you don't want the opposite either,
or something is a visual to just you don't.
Speaker 1: Want to be drinking your own urine.
Speaker 3: Yes, yeah, so it's it's kind of it's it's really
about I would have I would like an event modeling
to like, let's say, Richard, you have a you have
a system, and I don't know how it works, and
you could hand me a pile of specifications and documentation
and hope that I'm bored enough over the weekend to
go through it all, or we could sit down side
by side and you can say, hey, Adam, let me
walk you through some examples of how I use this system. Right,
I go, okay, so what do you do now after
you log in? Okay, you press this Okay, I understand.
You set it up, and now I can put things
in the cart and my customers can pay for things.
Speaker 2: Et cetera.
Speaker 3: It's like, very cool, Richard, thank you. I totally understand
how the system works. It wasn't that way more effective
than a bunch of papers sitting at my desk waiting
to be read.
Speaker 1: Right, So essentially taking from the user story down into
the system, what gets written, what doesn't get written about? Yeah?
Speaker 3: Yeah, so it's sort of like the closest thing I
would say that. It's like is sequence diagrams from UML,
except we take the middle pieces out and we really
talk about state the kind of the object on the
very far right in the sequence diagram and the user
interaction on the very far left, and this is kind
of the right size block for units of work. Those
state transitions we don't want to talk about get into
the weeds of like is this class a good abstraction
or not? That's highly subjective and also silos a lot
of the conversations into just the dev circles, so it
doesn't really have a good collaborative platform for talking with
your business users. Now State. I sometimes explain this as
like this, you know the pyramid you have in an
organization where we have your you know, boss, CEO, whatever,
they have a vision statement. That vision statement gets broken
down into a set of goals or whatever, and then
it gets keeps getting broken down into requirements, into actual
you know, implementation and tests. So it really fans out.
But there's that really good common area in the middle
of that triangle called understanding state. And as I go
through this, you know, storyboard of what what people see,
what gets stored in the system as the time moves on.
By example, you know, no branching, nothing like that, just
like no no flow charts. Is not a flow chart.
You really understand, you know what happens, and people can
work together using this. It's kind of like a blueprint.
If you go to a construction site, there's a big
blueprint on a big table. The carpenters and the and
the and the plumbers can can look at it. And
so the key there is that the carpenter knows exactly
where to cut the holes in the walls so that
the plumber can put the pipes through where they need
to go.
Speaker 2: Right.
Speaker 3: So there's that. I guess what we've kind of been
trying to do in this after industry ever since agile
is to do the small design up front, which was
kind of always the premise we'll get rid of big
design upfront because we don't want to We don't want
to be, you know, being kind of armchair architects for
a whole year planning these great goals and you know,
things that will never see the light of day because
we've never actually practiced them. So this, you know, this
event modeling can actually be done as little as an afternoon,
and it can also be done and often is done
as a way to maintain the system because you upgrade
your schematic of what's happening. So you know, if I
come back to a system four years later and we
do this often you kind of roll out the schematic
and say, hey, someone needs a feature and it requires
you know, this extra workflow to be at it, so
we'll make space on it. Plunk in what needs to
be done, do what's called information completeness check, which is
a real fancy way of saying, do I have a
source for that piece of information somewhere? And if the
arrow's doing add up, we know we're missing something and
so we're going to have to you know, this is
where we really understand the coupling in a system. We
start to actually see where you know, that field value
must come from. Okay, we probably need to add date
of birth on the registration page because we're obviously using
date of birth and the thing that we just imagined
we want to have in the next release. So that's
kind of how it works. I also think of old
history of when you had a vacuum tube television and
you opened up the back panel, you'd have the entire
schematic with the where each wire goes to which vacuum tube,
so that if something went wrong with your TV, you know,
it's not today's throwaway society where you go back to
Costco and return it. You actually, you know, had a
TV repairman and go and you know find that too.
And you know, I think someone mentioned that there's at
stores there used to be vacuum tube testers. We'd plug
in your vacuum tube and click and then see which
ones work or whatever. So we kind of want to
have that responsible way of maintaining our software systems. And
so an event model is a is a really human
friendly diagram of what the system's doing. And I also
call it inform architecture, which is really the backbone of
all architecture because no matter what cool stuff we're doing
in tech, it all serves the purpose of getting information
to people, right. And the reason that the screens and
the UX is in event modeling is because all systems
we build are for humans, and so we need that
human face to it. And so where previous attempts to
do even like business specific things like BPMN, oftentimes this
is more of an extra feature or a benefit that
you can or can't use, event modeling says, no, you've
got to have these things in here because humans are
using it. So I really want to know if my
process is at fifty percent, you know, with these steps,
if I navigate to this web page, what would I
see right? And on those relevant things, we kind of
do that, and so an event model is organized as well,
so you have your subsystems and swim lanes below, and
you also have the different users that are interacting with
the system at the top in their own swim lanes.
And the middle part is really like the watermark of
like the input and output, Like where does the information
come in? And then how is it project it out
to a particular screen, And you can connect all those
things together and it's a real fun, fast way to
get going, but also a really responsible way of maintaining
really crazy large systems. So we had these event models
that you know, span giant projects worth millions of dollars,
and so it ends up scaling from you know, startup
to giant enterprise. And it's kind of like skills like
this I kind of see as carpentry, right, Like if
you know the shape of wood, you can build a
really good chair, you can build a really good house. Right.
How does a good carpenter work at all these levels, Well,
they really understand the nature of what they're working with, right,
And so understanding information is kind of like the backbone
of being able to you know, build small systems or
build large systems.
Speaker 2: Right.
Speaker 3: You kind of a good system will have this no
artificial ceilings of how far they can go. So yeah,
that's kind of I get too excited talking about event model.
I can talk about it all day. So I hope
that was a succinct enough explanation kind of what's on
top of my mind after you guys introduced it.
Speaker 2: Does a tooling matter much here? Like it sounds like
a way of thinking about data, But I think about
the comment and using aka dot net for example, it's like,
is that help you lead to go the right way?
Speaker 3: It could, and it certainly was very important in earlier days.
I think now with the focus on how important information is,
especially with AI and all that, you really want the
maximum amount of things, So why not capture all of this?
And we're kind of blending to topics you're event sourcing
and event modeling because event modeling works for traditional systems.
We've had lots of people that love the notation and say,
you know, our company is just not ready for event sourcing.
We don't have the ability to shift the culture to
do it that way, but they still use event modeling
for that. So your question, Richard, is about kind of
two areas. So yeah, underlying technology, there's tooling there to
support event sourcing if you want, but you can use
it with traditional stuff, right, doesn't make it any harder.
But there's also the what do you use especially around COVID.
A lot of this stuff used to be done in
person before COVID, on whiteboards where you would use sticky
notes to kind of elaborate what's our workflow, you know,
what are we going to be capturing. Let's put up
some you know, mockups that we drew with with felt
markers on white pages and just put them across and
kind of say, yeah, that looks like a really cool system.
I can see this working, and I can.
Speaker 2: Yeah, And the tech is secondary the point there, right,
the system stands alone.
Speaker 3: Yeah, exactly, So that the cool thing about that is that, yeah,
it's an back of the napkin sticky note process that
kind of conveys the same information. But obviously since COVID
everything's gone online. Nothing beats in person kind of interaction,
especially when you're collaborating. But a lot of things were
brought online. So there's the advent of well real time
board changed to MIRO, and then of course Microsoft has
its own whiteboarding technologies and teams, and many others are
out there. There's open source ones like Diagrams, dot net
and on and on, Lucid, chart Excala draw. All of
those work as long as we can draw a rectangle
and connect them with arrows. You pretty much got all
you need for event modeling and you can get started
right away. And so the other thing that makes this
tech agnostic on the front end of actually designing it
is that it's really synonymous to what a lot of
people are happy with already. Most systems that you have
that people want to design, people are quite familiar with
mockups and they want, you know, mockups of the screens
that a user will see in generally, so a lot
of places already have kind of the basics in their
muscle memory to go through this kind of process. So
that's why it's getting quite a lot of traction.
Speaker 2: Yeah, it feels like you're just putting language around stuff
we were doing instinctually.
Speaker 3: Yeah, but there's some important caveats because a lot of times,
you know, one of our clients was plenty of Fish
and you know, to send a message from one user
to another. And for those that don't know, plenty of
Fish is a free dating site, so there's a lot
of like a free profile, so you could be talking
to a random stranger, could be someone that's not necessarily
been vetted as much as with another platform. So you know,
if you were to do a wireframe mockup of sending
a message from one user to another on a wireframe,
that would look like, oh, that's just two steps. There's
a send message and that oh this person's receiving it,
great specs, right, But like in the middle is about
twelve steps of we got to spam check, we got
to translate it, and you know, replace dollar signs for
essays and all sorts of tricks that people play to
do that. So you know, when we actually did this
with them, event modeling elaborates this to make this complexity
drawn out horizontally to actually see the size. So where
this makes an impact is in your agile estimation, so
or you have extra L T shirt sizes or whatever.
We kind of don't want to be subjective saying like, hey, Adam,
how hard do you think this is?
Speaker 2: Oh?
Speaker 3: I think that's an extra large or a medium T
shirt size? Highly subjective, right, Like does Adam really have
the good experience to answer this?
Speaker 2: You know, maybe this.
Speaker 3: Other person will give me a large or a small
depending on their experience. So we kind of want to
remove the subjectivity and rather than saying, you know, how
long is it going to take to send this to
get the work done to send this message to this
other person on this platform. I need to then see
and illustrate to the business in a human friendly way
that this is going to take twelve steps along the
way to transform the information and filter the information along
the way, and we can label those things such as
bad word filter and spam filter and you know alternate
character Unicode filter where people are trying to well, you know,
the old hack with a semicolon being replaced with the
Unicode version from I forget what it is. I think
it's an an Indian language of some sort, but it
looks like a semi colon, but your thing doesn't compile
because it's not actually a semi place.
Speaker 2: Some Unicode character tas like, why is that failing?
Speaker 3: I've watched three Days of Sleep and.
Speaker 1: We just did a Blazer puzzle on that where an
E looked like an E but it wasn't an E
and it was a cyrillic yeah something. Yeah, yeah, it's
not an E and everything compiled because we were instantiating
a new class name in the class name that we
were instantiating had that crazy E in it, and it
didn't work.
Speaker 3: Yeah, yeah, yeah, so anyway, I mean, this kind of
stuff was really pertinent to these guys and if they
didn't get you know, I think it's a lot better.
First of all, I think it kind of removes a
lot of the problems with imposter syndrome and gatekeeping in
organizations because if you remove subjectivity, you're really not putting
someone in a spot to be the judge of someone else.
And if you systematize things that like, can we just
work together shoulder shoulder looking at the system and kind
of you know, spread out this highly complex unit of
sending a message on this platform that's got these vulnerabilities
and explain how that actually works instead. But the trick
was always that that was always looked at as a
technical thing and always got chucked over the fence to
the devs.
Speaker 1: Right.
Speaker 3: But if we bring into the conversation a way of
describing these problems and solutions in a set of state
changes that's understandable by both side, and that's where we win.
Where we have this really collaborative environment now where we're
talking about everything that everyone cares about. And so you
know that goes to how we do specification. So we
do a lot of spec a specification by example from
the behavior driven design stuff with guys like Joshua Kariewski
and Dan North and others that have really pushed this.
Goyko is another one, so growing software with Objura, I
forget what it is. There's a there's a growing software book,
the Goose Book I think it's called that also talks
about a lot of this stuff. But really it's going
back to that human friendly thing. And the reason that
event modeling is a story like thing is because humanity
kind of built on stories.
Speaker 2: Right, yeah, how it's how humans work?
Speaker 3: Yeah, yeah, exactly like everything like you go to sales,
you go to any kind of domain. A story is
how we retain the most. Right, We'll never remember a
graph like we have a really cool graph about how
your system's done. Cool, but I'm always going to have
to refer to the graph to actually use it. Where's
the story really sticks in your head? So when I'm
done with the event modeling workshop or a meeting about
it and I was looking at it, actually retain at
much higher percentage of what was discussed because it sticks
in my head. As in a story format.
Speaker 1: And if you sing the story to the Barney song,
you'll have even more.
Speaker 3: Mind Yeah, I mean, do what you like on your team.
Speaker 1: Right, it becomes an earworm. Now you can't get it
out of your head, go to bed singing it every night.
Speaker 3: Now you're trapped exactly. Definitely, definitely. Oh that is really good.
I'm gonna I'm gonna have to use that.
Speaker 1: I'll be here for the rest of the show, folks, I.
Speaker 3: Know I'm taking notes.
Speaker 1: For more tips follow me and media.
Speaker 3: Can I hire you, Carl, I'm gonna We're gonna like,
we're gonna bring you on onto some of these difficult projects.
Can you play tub something that's kind of repetitive, right, nice.
Speaker 2: To you.
Speaker 3: It just goes on and on ends.
Speaker 1: But barbaro, no, no, no, I'm sorry.
Speaker 2: Anyway, we should take a break, Yeah, we should.
Speaker 1: It feels like a great place to take a break.
And we'll be right back after these very important messages.
And by the way, if you don't want to hear
these messages, you can get an ad free feed by
becoming a five dollars month patron at Patreon dot dot
NetRocks dot com. We'll be right back. You know. Dot
net six has officially reached the end of support, and
now is the time to upgrade. Dot Net eight is
well supported on AWS. Learn more at aws dot Amazon
dot com, slash dot net. And we're back. It's dot
net rocks. I'm Carl Franklin. That's my friend Richard Campbell. Hey,
and Adam Dimitrek is here. And we were just about
to sing tub thumping songs.
Speaker 3: So can we get the tub thumping as the ultro.
Speaker 2: Music days get knocked down.
Speaker 3: A camp, it just goes on and on.
Speaker 1: Yeah, and again I apologize for not going to sun track.
Speaker 3: Well, that's totally fine. Actually it's it's on track. Is
we're exploring why this kind of stuff works and the
way why my stories highly connected, you know, are if
we if we design our systems using tools that are
friendly to the human brain, I think we will be
way more successfully. So I think that's kind of the part.
And you know, if if em moling really didn't come
up as an idea, it actually was formulation of many
different things that worked in the industry. So one of
the things that worked was a workshop type of environment
versus a meeting, so that there's constructive things going on
and you're actually collaborating. There's no I just have action
items at the end. Of a meeting, like we actually
did stuff during the meeting, which is much better the yeah,
exactly like my meeting.
Speaker 2: Right.
Speaker 3: We've been in those places where like I just want
to go back to my desk and get something done,
but I've been sitting in meetings all day, right, So
we definitely have no meetings now, and.
Speaker 1: We're going to have a meeting to find out why
you have been not so productive.
Speaker 3: Yeh, exactly, Maybe a meeting about the meetings to see
what's meaning old cliche jokes at this point, I'm sure,
but yeah, so you know, one of those things was
the collaborative approach and having in person stuff. The other
thing was I already mentioned was the specification by example,
seeing actual examples to the system as a specification that's
a little bit more friendly to the human brain and
all that. We have obviously this idea of multiple models
to make sure that we can express what a specific
part of a workflow needs based on a common source
of truth, which is very easily implement if you are
doing events sourcing. Back again, as I say, it's not
necessary to do event modeling, but oftentimes they're highly complementary.
So there's also this idea which we touched upon of immutability,
So everything in here in terms of the source of
truth is not utable, and so this additive only approach
is also it gives you, you know, caching is way
easier when you're dealing with additive only, like you're just
moving up point you're to validate cash and things like that,
or see how far you caught up to so a
lot of you know, technical things are are much better.
It also opens up the door to functional style programming.
You don't have to have a functional language. So all
the f sharp proponents really do like events sourcing because
of this immutability part, and like you know, growing ledger,
it's really easy to feed that into your functions and
do mathematical map produce on these things and all that
kind of stuff left folds and all sorts of you know,
functional paradigms. But you don't need that. You can actually
explain those benefits in human language to business that you
have a guarantee that anytime you've had this history, if
you try to do this, you're always going to end
up with this result. So this idea of a pure
function enters into the arena as well where things that
you test in your unit tests, etc. Are always going
to be deterministic, so given the same inputs, you're always
going to have the same output. That makes for really
really strong unit tests and you know, brings a lot
of benefits there. So that's you know, all of these
things are are kind of at play. So you know,
things like domain driven design with organizing things within bounded
context so that things are related using ubiicuous language to
make sure that the terminology is something that everyone understands
for a particular context that ends up being embedded in
the event names and the event model. So all of
the things that you're trying to do with all of
the kind of best practices that I've seen kind of
you know, when I started a company, it's that we
don't have people like I don't have money to spend
on project managers. I don't have money to spend on
product owners. I don't have money to spend on QA.
I don't have money to spend on any of these
How can we make a system that takes care of
what those jobs took care of, or at least scale
their efficiency so that I don't have to hire twelve pms.
I can just hire one to do that to take
care of these projects. And so if event modeling was
kind of born out of needing to fullfill all those goals.
Speaker 1: I have a question for you about the back end
databases that uses your event store. Is it a typical
and Richard you might know the answer this too, is
a typical practice to sort of have a system running
in parallel or a database running in parallel that you
that is not online to the customers, but you know,
you keep a clone of it current all the time
so that you know when you do need to go
back in time and look at it from another perspective,
you don't have to spend you don't have to waste
time sort of dropping the you know, copying the database again.
Is that is that something that you do normally? Yeah?
Speaker 3: Yeah, oh yeah, all the time. I mean it's so
I know, I think I know where my background and
nightmares come from when you ask that question, because I've
been in systems where it's really hard to find if
you need two gigabytes or four gigabytes of the production
database to debug something, and that's those are not fun times.
And so when usually when we run these things, yes,
there is an active and a backup database of following
database that can do that. A lot of times, technologies
that Kafka can have something that keeps track of x
amount of days or weeks worth of data to go
and interrogate as you wish on the side. Yeah, and
it's really easy with event source.
Speaker 1: Is that usually something that happens in real time or
is it like an overnight Yeah?
Speaker 3: Yeah, yeah live. You want a live system, So a
lot of times we will have that. A lot of
times with most events stores, they are just sitting as
flat files on discs, either as a giant chunks of
you know, two hundred and fifty megabyte files that have
the events serialized within them, and you can just literally
just pull them as copies and then you're really you
can really leverage you know, your infrastructure and the hard
drive tech that you have to kind of have that
work done for you if you're mirroring.
Speaker 1: I imagine part of this calculus is you know, how
much time worth of events do we keep live? Yeah?
And when do they drop off and get backed up
or something?
Speaker 3: Yeah. So most mature events stores will have a hot
and cold part where things go to a colder kind
of storage that's slower, but it's there just in case,
and it kind of makes sense to how businesses run.
An active order will be on the SSD currently and
it'll be very fast to work with those events, whereas
obviously if you're coming back to the website, you know,
a year later and your shopping carts still there, you're
kind of like, hey, welcome back. Let's take a second
here to see what the heck you were doing. So,
and there's other strategies such as snapshotting and and closing
the books, which is really making sure that the streams
of data don't live forever, because that's not how usual.
You know, businesses run like a trading at af your
if you go to a stock trading exchange or whatever,
they they end their day, right, a reconciliation, right, So
there's a natural seam in the timeline for different things.
And so you know, same thing. If we were doing
this on pen and paper, the end of the year,
you probably empty out your filing cabinet, put it in
archives or something like that.
Speaker 2: Yeah, I mean, it's true that any retail store has
an end of day, Like you have to draw a
line somewhere to have measurable data, So you know, what's
the interval, Well.
Speaker 3: It's just also about management of information. I mean, this
is not rocket science here. This is not trying to
figure out brand news storing mechanisms or technologies about organizing
your information, just like you would with pen and paper.
You really want to not be swamped with disorganization or
too much information. So you're going to have a filing system,
you're going to have an archiving methodology if you're in
a serious business. And that doesn't really change that much
when you think about it when you're going digital from
pen and paper.
Speaker 2: Well, I would argue, usually you're not the one making
a decision that's a business decision. Yeah, there's probably even
general accounting practices that have to be followed for a
bunch of that.
Speaker 3: Oh yeah, there's a lot of regulatory things as well.
So those things are really very interesting to think about
when you're thinking about the motivation for this. But having
these good disciplines does give you a lot of things.
So for example, I told you about spreading out you know,
complex things, horizontal steps. What we found is that those
steps end up being really good units of work. And
we've actually said that we're going to have a standard
price for each one. So when we do work. We
do fixed cost only and we fix bugs for free
because both the client and the subcontractors are happy with
that deal. In fact, it's something that drives quality with
the right carrots and sticks. If I go super fast
and like do twelve steps in a day, I'm going
to have a whole bunch of bugs. Well, our contract
says that you have to fix anything before you get
to work on new work, So you're not going to
be able to charge for any work. If you just blit,
you know, totally chat GPT way through twelve things and
think they're popping up all over the place next week,
you're not going to be having a good time for
the next three weeks of fixing them. The things that
you kind of went through pretty quickly, so it self
adjusts really well, and I think both the clients and
the contractors appreciate that. And also, those units of work
are highly autonomous because now, as I said, we have
different projections, different you know, abstractions for each piece. So
if I do a bad job, I'm not impacting the
person working on the on the piece of workflow right
next to me, right as long as we're adhering to
those pre and post conditions of every little workflow step,
we're good. And if I do a crappy job, I
can replace that entire workflow step and I don't really
have to coordinate with the others. So this is like
the pizza sized team for Agile kind of goes away.
We can start to really measure the size of teams
based on how mature our design is. That's the thing
that pulls back. If I don't have time to make
an event model, then I only have, you know, enough
work for a team of size five. But if I
actually take the time to build out and understand how
the system is going to treat information, how many work
workflow steps I have, then I can have the latitude too.
Ten fifteen people work on the same thing, and we
know that they're not gonna step on each other's toes
and and things will click like lego. And that's kind
of how other engineering disciplines work. You know, car manufacturing,
all these other things are they have standardized pieces now
where you know you don't have to You can get
a rebuilt alternator from an alternative you know, some other manufacturer,
and they work just fine. So we're trying to really
make if you know this type of approach bring software
development to be more of a true engineering practice rather
than you know, being a lot of experiments and just
feedback cycles as we really wanted to, like, oh, iterate, iterate,
that's going to solve everything. Well, you know, we look
at other industries, they kind of take time to design
things a little bit. So we're kind pushing the needle
back a little bit to the middle because you know,
we came up, we came up through this idea in
the eighties and nineties of this big design up front
and the waterfall method and all this kind of stuff,
and you know, take a whole year to plan something
and then you know, things don't go as well when
in reality, we one all the way to agile, right,
the to just iterate, yeah, because we hate planning. So
I think, you know, agile missed a chance to really
focus on that small design up front, which is a
big opportunity. And I think don't mean driven design specific example,
all of them kind of attacked that a little bit
and said, hey, that's a good way.
Speaker 1: You iterate too fast and you're going to cause problems,
you know.
Speaker 2: Yeah, yeah, but I mean agile also said the customer
sitting beside you, right, like, and that's hard to do. Yeah, yeah,
the real part. The point here was that you don't
do a whole lot of design up front because it
separates even the customer. Have the customer involved and in
reality they don't want to sit around with you.
Speaker 3: Yeah, you get another person in the middle called the
product owners. Yeah, playing broken telephone. Yeah. So yeah, that's
that's a lot of a lot of good things have
come out out of it, and I think I think
a lot of them, as I said before, are human benefits.
Were gatekeeping and uh and and imposter syndrome go away.
Like we've had people that have worked on our projects
that are just fresh from another industry. There's a work
Safe BC. Someone got injured on the job and they
had to switch careers and work Safe BC augmented their
pay for us. But they were able to start this
because you know, each of these workflow steps, at least
in event sourcing, is identical. Like there's only two patterns.
So you're either working with a command handler or you're
working with a read model. And if I'm a new person,
all I have to do is like, hey, Tim, how
did you do that command handler? I copy their code
and just and all that. It's like the same pattern
over and over again. So this repeatability is highly valuable
because you get a lot of cadence. It also gives
the excellent you know, estimates because you're doing the same
thing over and over again. So you're sample sized growth,
you know, mathematically speaking, your sample size for how long
things take. You get a really good idea. Whereas if
you were to throw a whole bunch of patterns all
the time at every problem, you're going to have a
smattering of small amounts of statistics for each pattern, and
that's not going to be enough confidence to say that, yeah,
I can do that for X amount of money. You're
you're not going to have that amount of track record
with that. So by repeating you know, a few core
patterns over and over again, you really do that. And
after ten like we've been in business for about ten
years now, we've got like a ton of statistics to
go on. And so when you know, when we say
a project, will you know cost this much and take
this much time, it's pretty spot on, especially if the
client is there collaborating on the design saying yeah, these
are the screens we want, Yeah, these are the steps
that have to be taken to capture this information. From that,
we can say, yeah, everyone's happy to sign on for
you know, fixed costs and all that, and I think
something that's really worthwhile and you're confident and you should
be able to do for fixed costs. That I think
is a sign of like maturity to be able to
have you know, people take on that quote unquote risk
and it's actually de risking a lot for both sides.
And so back to that point, you know, someone that
you know came into to work in software for the
first time, they felt really at home because there was
really good guardrails of how a framework within which to
learn programming. So they can make all sorts of mistakes
when they're making a command handler or they're making a
read model, and they could iterate themselves to learn that.
And of course their throughput is not going to be
as much. They get paid the same amount for that
piece of work as someone that's senior, so it might
take them three weeks to do it. A senior person
might take three hours if they're really really good. So
we've seen a huge variance. It's also exposed a lot
of the inequality in the industry, like a staff engineer's
a senior engineer level one versus a level two, or
there's like a five thousand dollars difference in pay. Well,
the difference in pay for levels of skill we've seen
is insane. We've had people make as low as three
thousand dollars because they're new, to as high as seventy
thousand in a month because they're so good. It's insane.
How the variance of people's ability or incentive or devoting
themselves to the amount of time, it's been very enlightening,
and I just like the fact that you know, it
kind of manages itself because when you have these standards,
you have a system that kind of operates on its
way on its own. You don't need to fill a
whole bunch of other jobs to manage it, or at
least if you have those jobs, you can scale out
the amount of work under those jobs way further out.
So you know, we've been pretty much a flat organization
much like get hub started or Valve. It's just myself
and everyone else doing the works, about twenty thirty people
at peaks when we have larger projects, and there's really
very little need for any kind of management like these
event models kind of you know, we color them in
as the project moves on. There's no backlog, so as
we look at the schematic people just fill in the
rectangles that represent the slices of the workflows. You know,
they paint them yellow maybe if it's in progress, and
the pink them green when they're done. And we always
look at it and say, hey, this looks like it's
fifty percent done. And some have done automation of miuro,
for example the Whiteboard to kind of use its API
to give you like a burn down chart equivalent. Right,
they'll count how many of these slices are actually colored
in versus not, and then you can see how many
your own progress instead of have a nice little bar
graph shows you what's going on. So we've replaced all
the tooling with just an event model. But we're the extreme,
like we just want to show what's possible, and most
organizations are not going to be able to do that,
we understand, but at least we kind of show what's possible,
and then you know, for most people that's an answer
somewhere in the middle. So we've had to integrate with
Jira and other things for certain projects because that's what
they have in their organizations. That's fine. You can translate
these things and we're happy to do that so it's
compatible with other things. But we always want to just
push the envelope and and just show what can work
so that people have the confidence to pick something in
the middle.
Speaker 1: Where can we find these tools in guidance from you
and yours?
Speaker 3: Ah? Well, I just yesterday I finally got a paper
copy of Martin Dilger's Event Sourcing Understanding Event Sourcing Book.
I wrote the forward for it because it's the first
book that puts that writes about event modeling and event
sourcing together. So it has in it examples that you'll
find some of them online. I mean, I've been doing
a lot of If you want to learn anything in
a book, you can probably find it for free online.
But this is like a concise kind of way of
looking at it all in one place, and a lot
of people want that. But yeah, you can see. I
don't know if I can be legible or not, but
yeah you can see. I guess the people who are
listening to the radio they can't see what I'm showing.
Speaker 1: But anyways, Okay, it looked like a page with a
white background, wait, hold on and black writing.
Speaker 3: Yeah, so it goes from from zero to fully implemented system,
really good hands on book, and it's been on Lean pub.
This is the first It's just got released on Amazon,
so I just ordered as soon as I could. Cool,
but it was a It's been on lean pub for
about five weeks now and it's been holding the top
spot wow for weekly sales the whole time. It's it's
been something that a lot of the community has been
asking for because a lot of people have been doing
event modeling or trying to you know, promote it and
use it because they like it and they want to
carry it through to the rest of the organizations. So
you know, I've been threatening to write a book myself
on it, but running a business and doing that is
a little bit too much. But I'm glad that Martin
did it and included it.
Speaker 2: So I wrote the forward.
Speaker 3: I wrote the forward.
Speaker 1: Yes, is there anything that is there anything that you
wish you would have written in there that you didn't
have no space to?
Speaker 3: Martin's a kindred spirit. I met Martin in Munich in
last year about this time, maybe a little bit longer,
maybe an extra month, think the end of October something
like that. Anyway, I was giving an event modeling presentation
at their event driven meet up there and and he
drove in, you know, hundreds of kilometers from his small
town near Munich to meet me. And that's kind of
I think when he started to write the book, he
was very inspired by a lot of the work that
the community has been doing. And the original article that
I wrote was from really twenty eighteen that kind of
got pushed. I think I wrote it on Medium. I
forget where I wrote it, but it went viral in
the fall of twenty eighteen October, and I don't know
what the heck was going on, why my phone's going off,
but it got the top story on Hacker News, and
I'm like, what the heck? Why is everyone so interested?
And that kind of gave me like, Okay, this is
not just how we were. People actually want the same
things as we want. They want to do things this way.
So I made a website for it, eventmodeling dot org,
and I basically stick all the resources on there. I'm
not very good at keeping it up to date as much,
but I try to stick in like links to books
and research and the videos, the YouTube channels of examples,
it's all on there, link to that. But yeah, the
history of how this whole thing evolved, it wasn't I
did not intend to make event well, it was just
you know, we found a really good way of working
that's effective and then captured you know, how we worked
into both a process and the notation that people could reuse.
And so that's essentially what event modeling is and from it,
you know, other people are writing books on it. There's
a lot of tools also that kind of Martin has
an ad in to MIRO that allows you to more
easily manipulate things that are event modeling on a mirror
board to what to mural you know, MIRO, the real
time board. It's now called MIRO the Whuro Collaborative whiteboard.
So a lot of companies use MIRO as a whiteboard.
I mean same you know, just like maybe dot net
teams use the white collaborative whiteboard. Yeah, exactly. Yeah, so
it used to be called real time board. Like if
you look back in the day, that was kind of
a very popular thing in the startups, and I don't know,
ten fifteen years ago, but they rebranded I forget exactly
how long to Miro because maybe those copyright things are
just they wanted a unique name. I don't know, you
can ask them, but anyway, they Yeah, so Martin's written
an ad in for that. Other people have written plugins
that basically take an event model and they and it
interrogates it and creates all your tests for it, I
like for your solution, which is really cool because yeah,
these given when ND tests in the style of a
specification by example BDD style tests are really good with
event solutions. You just say, what's my given You always say,
you know, your setup is always a set of events
that you can just pull directly from the event model,
and then your when what you're testing is the command
that you're trying to poke the system with, and then
your assertion is always that you it spits out the
event you expect. So it's really awesome and in fact,
actually there's another benefit of this is that things like
integration tests and acceptance tests, we've pushed them to be
subcutaneous and then have the green boxes from an event
model and kind of capture long running processes. So we've
kind of shoved all integration testing to be just a
unit test. So even if we have like a end
to end test of some long process. The projections that
we use encompass that. And because there are pure functions,
these run within seconds, so we don't use any mocks
anything like that. It's just all poco pojo, whatever your
language is. There are all the property bags that sit
there for setting things up, and in fact there's a
highly kind of opinionated way of doing things, to the
point where I'm thinking that most people will rewrite their
own test harnesses for unit testing, because you're taking slices
of a history that you can predefine as in the ray,
and then you can take slice length of zero from
the top to say, what's the default view of this window,
and then you take the next one that's your next
test case. Okay, what happens when this event's in there?
Does it change anythink great like that you can assert
on that. So it ends up being quite quite neat,
and in fact, below each slice in the event model
we do have like an alternate little timeline that points downwards,
and there we have a different sample of events and
happenings that are particular to that workflow. So an example
will be an invoice. The event model kind of wants
to show me the happy path of how the system works.
So you don't want about twelve different steps to show
just how differently the event the invoice can look. It's
just gonna take up way too much real estate. So
we kind of go downwards and say that, Okay, here's
some scenarios of like if you have a discount code,
you're shipping to a different country, et cetera, et cetera,
all sorts of different things volume, discount, reward points, whatever.
You can put those events to make different scenarios down below.
So you're not kind of polluting the space of the
general idea of what the system does with the event model,
but you're diving into those nitty gritty specifications that you
need to build a robust system. What's really interesting about
this NAI is that when I did this on the
stream just last week or two weeks ago, I took
a screenshot of that set of events and on the side,
what does that invoice look like? Along the way is
an arrow down. I took a screenshot of this an
incursor AYI, which is a fork of vs code, pasted
that into the chat window and say finish the tests,
and it did exactly that. It made an addition to
the test correct first try. I'm not kidding. First try,
I was blown away. So yes, AI hallucinates, but not
when you give a good specs relation like yeah, and
we know what's more interesting is that AI has been
trained on human interactions. We talked about stories, we talked
about timelines. Guess what happens when the thing that you
show it or ask of it is following storylines the
things that it's been trained on. It's been trained on conversations.
Conversations are like stories. So I think that's why it
got it spot on because the format of what I
was giving it wasn't the mockup of a UI. It
wasn't anything weird like UML diagram with entities connected in
whichever way. It was a timeline, and we showed how
information changed. It got that on the first try. I'm
not kidding you. You should try this yourself. If you're
wanting to test where AI hallucinates where it doesn't, I
can give you an example of where it does not.
And it's these things of these given win then specifications
or in the case of state views like I just
have given then because there's nothing to test like given
some events. This invoice will look like this. There's no action,
so slightly different take on it, but the main way
that it works as the same. So I've been floored
just by you know how much this helps in the
whole AI thing, just by having a better structure in
terms of how you think about your systems, Like you
get way more help from these tools. So yeah, I
don't mind.
Speaker 1: Yeah, Before before we stop here, I had I want
to get in the way back machine for a second
and ask you if you remember a technology called Windows
Workflow Foundation. Yes, man, why are you laughing?
Speaker 3: I do remember bistock? Do you remember bisdoc?
Speaker 1: Yeah? So what what was your impression of workflow Foundation
back then? And you know, why don't we even talk
about it anymore?
Speaker 3: I think, Well, it's a more general question to me
about case tools and having Dragon drop development and you know,
human facing kind of way to automate systems. I think
we always wanted this way of like why do I
have to talk to a developer to like get things done?
Why can't I just have something that's good enough framework
so I can stick the screens on some kind of
an interface and then press go and it'll do it
for me. I think that's what we've secretly wanted, and
I think that's kind of what fell out of event modeling.
So just like UML, I mean I talked to Grady
Butcha last year in Hawaii or was it the year before,
I forget anyway, he lives in Maui. It does really
good work with conservation of whales and all that. But
he's he's really interested in how UMLGA kind of taken
away to be a case tool to generate code instead
of being a general notation to do that. And I
think the UML two point zero folks kind of went
and said, we can build a business around mL to
create solutions kind of for free or buy the business.
And I think, I think what you're taught talking about,
Carl's kind of this this approach of like, hey, we
can take you know, a human recognizable way to talk
about a workflow of information and kind of press go
and it'll do it.
Speaker 1: I think without this kind of an answer to rational rose,
wasn't it. Yeah?
Speaker 3: Yeah, the rough process, all these all these different all
these different things that we've gone through. I think with
AI it's it's reopening that obviously as we see you know,
I definitely think that the programming languages that we use
in the future are not going to be the same
programming languages that we do to use today, at least
not for the same purposes anymore. That level of abstraction
is being bumped very hard right now up again, right
just like we had from you know, assembler to compiled
languages to whatever interpreted languages, et cetera. So I think
the same thing's again happening out of very rapid pace
because in essence, I think AI right now has really
just taken what we do with stack overflowing Google searching
from four hours to be four minutes type of thing, right,
So that is the affordance of the level of abstraction.
So you know, when I'm when I'm taking a snapshot
of you know, some sticky notes on a whiteboard and
putting it into cursor AI, and it's giving me the code,
that's you know, I can feel the change, right I can.
I know that that would have taken me to write
those things wouldn't have been you know, a second or
two or three or however long it took the chat
to produce. It would definitely be taking minutes, an hour
or whatever. And it even caught something that I there's
an assertion in there that I didn't think of. And
when one of the events was uh, you know, this
was for a conference organizing software, and it was I'm
going to change the name of a room because I'm
adding rooms to set up the conference. The assert that
the AI ended up putting in there was make sure
that the old name doesn't exist in the collection already.
I missed that, Like I just wasn't thinking, and I'm like, oh, yeah, right,
of course, Like I could definitely have a bug in
there where instead of renaming, I just added another room
and left the old one in there, right, or something
like that. So that's a really good assert and it
did it for me. Okay, that's really good. So we
all have like spikes of being really good, but we
also have things when we're not on and we'll miss things, right,
And I think AI draws a kind of a safety
net at the average, so if you ever make a mistake,
you're obviously falling below average of what's out there, and
the AI will catch it for you. So you know,
if you're expressing things in a story like manner and
you're really in tune with what AI has been trained on,
I think event modeling because of its story like nature,
the way that these things are specified, they have basically
given a very low probability of hallucination with these things,
so you could go incredibly fast asked with event modeling
and event sourcing. Event sourcing for the point that you're
working with, you know, multiple purpose built models for just
that one workflow step, which is a very finite scope.
And I think AI does a tremendous job when the
scope is finite, Like really you know it? Yeah, if
you say, hey, build me an online store, it will,
but it's probably not what you're the one you're imagining, right.
Speaker 2: Right, Yeah, it's not the one you want.
Speaker 3: Yeah. If you say, like, hey, I want to like
add this item to my shopping cart, and this is
the screen and the specific you know, it'll give you
exactly almost exactly what you mean.
Speaker 2: Yeah.
Speaker 1: Well, Adam has been wow, drinking from the fire hose
for the last.
Speaker 3: I guessed about this, but full.
Speaker 1: Of meaty goodness. So thank you very much.
Speaker 3: Yeah, thank you guys for having me. And if anyone
wants to find out more event modeling. Dot org has
all the all the links search for event modeling. It's
the top link and definitely get the book from Martin.
He's done such a good job, working to irishly on
so many chapters day in and day out, so he
deserves all the credits there. And he's been a core
member of the community over in Germany doing that, so
you know, I'm really happy for his success and it
helps our entire community. There's also a discord group that
we have if you have questions about this. Martin, myself,
all sorts of other people are there to answer questions.
It's a highly active group. Is messages there every single
day about this stuff. So if it's event sourcing or
event modeling, even domain driven design topics pop up in there,
anything around this whole way of working, you'll find good
people there to help you. I'll be there to help
you if I'm not. There's others, So thanks guys for
having me. And yeah, we have workshops too, so all
sorts of things on that site. I hopefully we will
have a few. Actually, we also had our first event
modeling conference in Vancouver and one in Germany this year,
so starting to grow. So anyway, we'll have to have
your booth that one of these when we grow big enough.
Speaker 2: To have you. Yeah, sure, Kevin do that.
Speaker 3: That'd be fun, that would be really awesome. So thank
you long overdu and I thank you so much.
Speaker 1: Thank you, and we are again. I wish we had
you on before, but wow, what a show. Thanks again
and we'll talk to you next time on dot net rocks.
Dot net Rocks is brought to you by Franklin's Net
and produced by Pop Studios, a full service audio, video
and post production facility located physically in New London, Connecticut,
and of course in the cloud online at pwop dot com.
Visit our website at d O T N E t
R O c k S for RSS feeds, downloads, mobile apps, comments,
and access to the full archives going back to show
number one, recorded in September two thousand and two. And
make sure you check out our sponsors. They keep us
in business. Now go write some code, See you next time.
Speaker 3: You got jad Middle Vans