1
00:00:01,080 --> 00:00:03,799
Speaker 1: How'd you like to listen to dot NetRocks with no ads?

2
00:00:04,440 --> 00:00:04,799
Speaker 2: Easy?

3
00:00:05,360 --> 00:00:08,560
Speaker 1: Become a patron for just five dollars a month. You

4
00:00:08,599 --> 00:00:11,320
get access to a private RSS feed where all the

5
00:00:11,359 --> 00:00:14,599
shows have no ads. Twenty dollars a month, we'll get

6
00:00:14,599 --> 00:00:18,440
you that and a special dot NetRocks patron mug. Sign

7
00:00:18,519 --> 00:00:34,560
up now at Patreon dot dot NetRocks dot com. Hey

8
00:00:34,600 --> 00:00:37,240
guess what, it's dot net rocks. I'm Carl Franklin at

9
00:00:37,280 --> 00:00:41,039
amiraterid Cabell. We're here again for the nineteen hundredth and

10
00:00:41,079 --> 00:00:42,399
sixty first time.

11
00:00:42,600 --> 00:00:43,039
Speaker 2: Well you.

12
00:00:44,479 --> 00:00:47,920
Speaker 1: Okay, you're here for the eighteen hundred and sixtieth time.

13
00:00:48,159 --> 00:00:50,000
Speaker 2: I think something like that. Second.

14
00:00:50,119 --> 00:00:55,039
Speaker 1: I'm the new guy, remember new guy new the new guy. Yeah,

15
00:00:55,079 --> 00:00:57,880
we are the OG podcast certainly when it comes to development,

16
00:00:58,000 --> 00:01:01,359
and one of the first five that's still existence since

17
00:01:01,439 --> 00:01:05,120
podcast hit the ground running. We've been going since August

18
00:01:05,439 --> 00:01:08,959
two thousand and two, A long, long, long, long time.

19
00:01:09,159 --> 00:01:11,959
Speaker 2: It's been a while. Yeah, how are you, Richard? I'm good.

20
00:01:12,000 --> 00:01:15,200
It's summertime, and summertime it's good. Sometimes it's beautiful on

21
00:01:15,239 --> 00:01:15,560
the coast.

22
00:01:15,879 --> 00:01:18,640
Speaker 1: It's a little hot where I am, but it's not bad.

23
00:01:19,040 --> 00:01:20,959
Speaker 2: It's not bad. It could be worse. Well, and she

24
00:01:21,040 --> 00:01:24,319
who must be obeyed is turning sixty, so I've well,

25
00:01:24,319 --> 00:01:25,920
at this point we'll have thrown that party.

26
00:01:26,400 --> 00:01:30,680
Speaker 1: So wow, it's always congratulations Stace. All right, let's roll

27
00:01:30,719 --> 00:01:33,680
the crazy music because I've got something for Hannas for

28
00:01:33,799 --> 00:01:35,280
better no framework awesome?

29
00:01:43,079 --> 00:01:43,959
Speaker 2: All right, man, what do you got?

30
00:01:44,079 --> 00:01:46,280
Speaker 1: Since this is episode nineteen sixty one, you can go

31
00:01:46,319 --> 00:01:50,120
to nineteen sixty one dot dot me and that brings

32
00:01:50,159 --> 00:01:54,560
you to this article from Menga, which is just somebody's

33
00:01:54,560 --> 00:01:57,719
blog I think. I don't even know the name of

34
00:01:57,719 --> 00:02:01,719
the person, doesn't even say all right, but anyway, it's

35
00:02:01,799 --> 00:02:06,400
called computerized guitars and whether they're worth buying or not.

36
00:02:07,400 --> 00:02:10,960
I know, Hanness plays guitar and makes guitars and yeah.

37
00:02:10,919 --> 00:02:11,840
Speaker 2: Builds guitars.

38
00:02:11,919 --> 00:02:16,599
Speaker 1: Yes, he's a guitar guy, right, Yeah, So this article

39
00:02:16,800 --> 00:02:23,000
basically says nobody likes these electronic you know, computerized guitars. Really,

40
00:02:23,000 --> 00:02:25,439
nobody likes them. Nobody wants one.

41
00:02:25,560 --> 00:02:29,240
Speaker 3: There's some weird experiments out there, like there are Gibson

42
00:02:29,280 --> 00:02:34,120
experiment with de robotic tuners and volunteery that that's great,

43
00:02:34,240 --> 00:02:36,759
and nobody seems to want that on their guitar.

44
00:02:36,680 --> 00:02:37,759
Speaker 2: That's just it. You know.

45
00:02:38,120 --> 00:02:41,520
Speaker 1: The sales say that they're cool, but nobody wants them,

46
00:02:41,560 --> 00:02:44,360
like the Gibson Firebird X, which is I think the one,

47
00:02:44,479 --> 00:02:46,680
or Firebird ten, which is I think what you're talking about,

48
00:02:47,439 --> 00:02:50,800
and the Les Paul Robot guitar was another one. But

49
00:02:51,520 --> 00:02:55,680
this is without question the most computerized electric guitar in

50
00:02:55,680 --> 00:02:59,639
the market right now. It has everything on it. The

51
00:02:59,680 --> 00:03:03,199
only it doesn't have is sales. Nice nobody bought it,

52
00:03:03,319 --> 00:03:08,039
and Gibson actually ended up crushing, like with a bulldozer,

53
00:03:09,000 --> 00:03:11,719
about a hundred of these things because they were a

54
00:03:11,759 --> 00:03:15,840
liability to have on the books, because they got had

55
00:03:15,840 --> 00:03:18,159
to get rid of their inventory, and because nobody was

56
00:03:18,199 --> 00:03:18,719
buying them.

57
00:03:18,960 --> 00:03:24,879
Speaker 3: Weirdly, Yeah, like every every guitar manufacturer that does strangely

58
00:03:24,960 --> 00:03:29,360
innovative stuff has been has been having trouble selling them.

59
00:03:29,439 --> 00:03:31,840
Like my favorite guitar that I own is a park

60
00:03:31,919 --> 00:03:35,520
Or Fly, which was way ahead of its time, and

61
00:03:35,599 --> 00:03:38,759
they struggled to sell them. Yeah, although they were selling

62
00:03:38,800 --> 00:03:41,520
guitars that were actually work twice what they were selling

63
00:03:41,560 --> 00:03:45,360
them for, but nobody bought them because they were so unconventional.

64
00:03:45,479 --> 00:03:49,199
Speaker 1: Yeah, and so let me just point out the other

65
00:03:49,199 --> 00:03:53,080
ones here the Fender Veg stratocaster, and I actually have

66
00:03:53,240 --> 00:03:55,280
one of these, but it was before that it was

67
00:03:55,319 --> 00:03:58,319
the Fender Veg. It's a Fender strat, but it also

68
00:03:58,439 --> 00:04:02,120
has the role In logo on it because you can

69
00:04:02,199 --> 00:04:07,280
connect it to the rollin VG system and it's got

70
00:04:07,280 --> 00:04:09,879
the right pick up in there and all. But as

71
00:04:09,919 --> 00:04:14,080
a strat, it's just kind of bleuh right, I have

72
00:04:14,400 --> 00:04:17,399
a strat plus that I love. I mean, it's hard

73
00:04:17,439 --> 00:04:19,160
to keep in tune and all that stuff, like a

74
00:04:19,279 --> 00:04:22,279
regular strat is, but at least it's a good sounding strat.

75
00:04:23,120 --> 00:04:26,720
Speaker 2: The isn't the question here why people play guitar, because

76
00:04:26,839 --> 00:04:30,480
most people who play guitar aren't making money playing guitar. No,

77
00:04:30,680 --> 00:04:32,079
that's true, sadly no.

78
00:04:32,759 --> 00:04:36,920
Speaker 1: They also mentioned the epiphone Les Paul Ultra, which has

79
00:04:36,959 --> 00:04:39,319
a USB port where you can connect the guitar to

80
00:04:39,800 --> 00:04:43,360
you know, your computer. The problem with that is that

81
00:04:45,920 --> 00:04:48,879
he says here too, machines and computers just don't mix

82
00:04:49,279 --> 00:04:52,319
when it comes to guitars. An electric guitar is a

83
00:04:52,360 --> 00:04:54,959
machine that by nature is a very physical instrument. This

84
00:04:55,040 --> 00:04:57,920
isn't like a synthesizer where it just sits there and

85
00:04:57,959 --> 00:05:00,360
you play it with a guitar, you sit down way that,

86
00:05:00,399 --> 00:05:02,240
you stand up with that you move around playing and

87
00:05:02,240 --> 00:05:07,839
so on. But most players consider these computerized guitars not

88
00:05:07,879 --> 00:05:11,639
real instruments because, let's face it, the sound of playing

89
00:05:11,680 --> 00:05:17,199
a synth through a guitar is just no, it's just bad.

90
00:05:19,600 --> 00:05:22,480
So they're out there. I think if I was going

91
00:05:22,560 --> 00:05:24,839
to get one, I'd just get an automatic tuning one

92
00:05:24,839 --> 00:05:25,519
and leave it at that.

93
00:05:25,759 --> 00:05:30,639
Speaker 3: Actually that system works, it's not that yeah, yeah, it's

94
00:05:30,759 --> 00:05:33,680
just good. Well, in this blog post is thirteen years old.

95
00:05:33,759 --> 00:05:36,240
You think the technology has probably moved on a little

96
00:05:36,240 --> 00:05:36,839
from there.

97
00:05:36,959 --> 00:05:39,199
Speaker 1: Yeah, a little bit, but I mean those are still

98
00:05:39,319 --> 00:05:41,680
not that much though. Those are still the models that

99
00:05:41,959 --> 00:05:44,199
you know that people like, except for the Fiber ten,

100
00:05:44,279 --> 00:05:46,519
which is not available anywhere.

101
00:05:46,639 --> 00:05:50,199
Speaker 3: Actually, the musician that has done the weirdest stuff to

102
00:05:50,839 --> 00:05:53,079
some of their guitars that a lot of people might

103
00:05:53,120 --> 00:05:57,079
know about is Matt Bellamy from muse Be built in

104
00:05:57,199 --> 00:06:01,720
like x Y controllers that control synthesizers that were like

105
00:06:01,839 --> 00:06:06,000
controlled from his guitar and built in effects into the

106
00:06:06,000 --> 00:06:09,800
body of the guitar. Like that had more electronics in

107
00:06:09,879 --> 00:06:13,199
it than a lot of other instruments out there.

108
00:06:13,399 --> 00:06:13,639
Speaker 2: Right.

109
00:06:13,720 --> 00:06:16,600
Speaker 1: Well, and then you got guys like Brian May who

110
00:06:16,720 --> 00:06:20,279
just made a very unique sounding guitar working with phase

111
00:06:20,920 --> 00:06:25,000
cancelation and phasing and all that stuff. But you know

112
00:06:25,040 --> 00:06:28,839
he's just just built by himself, Yeah, and his father, Yeah, out.

113
00:06:28,680 --> 00:06:32,439
Speaker 3: Of very unconventional woods in the guitar world. He used

114
00:06:32,480 --> 00:06:34,680
things like oh, which nobody he uses.

115
00:06:35,040 --> 00:06:37,959
Speaker 1: Yeah. So anyway, that's what I got today. And I

116
00:06:38,000 --> 00:06:40,439
thought we would have a nice conversation about guitars, and

117
00:06:40,480 --> 00:06:40,959
we did so.

118
00:06:41,240 --> 00:06:43,920
Speaker 2: Yeah. Richard, who's talking to us today, grabbed a comment

119
00:06:44,000 --> 00:06:46,199
off a show nineteen thirty nine, which is the one

120
00:06:46,240 --> 00:06:48,920
we did with Jeremy Miller talking about vertical slice architecture,

121
00:06:48,920 --> 00:06:51,319
and I know we got into events, sourcing and things

122
00:06:51,319 --> 00:06:53,600
with him at one point or another. Two. This comment

123
00:06:53,639 --> 00:06:57,360
comes from cash bon Fields, who said, you mentioned the

124
00:06:57,360 --> 00:06:59,639
buzz factor, which is how many people could be hit

125
00:06:59,680 --> 00:07:02,199
by a by while the project still survives. I have

126
00:07:02,279 --> 00:07:05,079
been recently considering the opposite, how many people should be

127
00:07:05,160 --> 00:07:07,079
hit by a bus for a project to be effective.

128
00:07:08,560 --> 00:07:11,079
The bus should most often be used for selecting managers,

129
00:07:11,079 --> 00:07:15,199
though I think there's a little anger in their cash.

130
00:07:15,240 --> 00:07:19,759
You want to talk to someone, don't don't hurt anybody. No,

131
00:07:20,079 --> 00:07:23,439
I get you. You know, there's definitely that effect of this.

132
00:07:23,800 --> 00:07:26,120
You know, how many cooks before you spoil the soup

133
00:07:26,279 --> 00:07:29,879
kind of thing, right, And we were six months behind

134
00:07:29,879 --> 00:07:31,480
on the project, so they had a developer. Now we're

135
00:07:31,560 --> 00:07:38,079
nine months behind on the project. People don't understand how

136
00:07:38,079 --> 00:07:40,240
to fix things. Hey, I got you the I got

137
00:07:40,240 --> 00:07:42,759
your book Mythical Man month, but actually got you two

138
00:07:42,759 --> 00:07:47,720
of them so you can read it twice as fast. Boom, yeah, Cash,

139
00:07:47,759 --> 00:07:49,199
Thank you so much for your comment, and a copy

140
00:07:49,199 --> 00:07:50,560
of music Coba is on its way to you. And

141
00:07:50,600 --> 00:07:52,199
if you'd like a copy of music Cobe. I read

142
00:07:52,240 --> 00:07:54,120
a comment on the website at dot and rocks dot

143
00:07:54,160 --> 00:07:56,600
com on the facebooks. We publish every show there, and

144
00:07:56,639 --> 00:07:58,199
if you comment there and I read it on the show,

145
00:07:58,240 --> 00:08:00,360
we'll send you a copy of music. Go buy Cobey

146
00:08:00,439 --> 00:08:01,319
is still going strong.

147
00:08:01,560 --> 00:08:05,959
Speaker 1: Twenty two chapters if you call them or episodes or tracks,

148
00:08:06,040 --> 00:08:06,639
I guess I.

149
00:08:06,639 --> 00:08:07,600
Speaker 2: Kind of like chapters.

150
00:08:07,720 --> 00:08:10,879
Speaker 1: Twenty two tracks, yeah, whatever you want to call them.

151
00:08:10,879 --> 00:08:13,680
There's twenty two musical tracks and they're all twenty five

152
00:08:13,680 --> 00:08:17,639
minutes long, perfect for your Pomadoro technique. Music took code

153
00:08:17,639 --> 00:08:20,240
by dot net all right, before we bring on Haness

154
00:08:20,360 --> 00:08:25,759
what happened in nineteen sixty one besides John F. Kennedy's inauguration,

155
00:08:26,519 --> 00:08:29,120
after which he immediately invaded.

156
00:08:28,720 --> 00:08:33,679
Speaker 2: Cuba by pigs thigs. Yeah, I don't know, just parallel,

157
00:08:33,759 --> 00:08:36,000
maybe kind of a hairy year, no two ways about it,

158
00:08:36,039 --> 00:08:36,720
and without a dough.

159
00:08:37,200 --> 00:08:40,000
Speaker 1: Yeah, the establishment of the Peace Corps and Juriga Garin

160
00:08:40,039 --> 00:08:45,639
became their first official human to travel into space. Additionally,

161
00:08:45,720 --> 00:08:49,120
the and directly into orbit too, you know, yeah, she

162
00:08:49,440 --> 00:08:51,679
orbited as opposed to you know, the US first effort

163
00:08:51,720 --> 00:08:54,039
with Alan Shepard in the sub ardable flight. Yeah, yeah,

164
00:08:54,240 --> 00:08:58,240
so I know, there's all the Beatles came in, you

165
00:08:58,279 --> 00:09:00,600
know around there, I said, the Peace Corps, some nuclear

166
00:09:00,639 --> 00:09:05,159
testing was going on in the Soviet Union, and the

167
00:09:05,200 --> 00:09:08,399
Academy Awards thirty third Academy Awards took place, with the

168
00:09:08,440 --> 00:09:11,639
Apartment winning Best Picture. You know, just some random trivia.

169
00:09:11,679 --> 00:09:15,080
But you've got the reallest Richard, what really happened in

170
00:09:15,159 --> 00:09:16,000
nineteen sixty one?

171
00:09:16,399 --> 00:09:18,720
Speaker 2: I mean I always go off to the invention side,

172
00:09:19,200 --> 00:09:21,639
just because you know, so many cool things are made.

173
00:09:21,720 --> 00:09:25,120
Sixty one is when the first industrial robot is deployed

174
00:09:25,120 --> 00:09:28,840
into a factory. It's called Unimate. It had been developed

175
00:09:28,840 --> 00:09:32,399
in the fifties by George Deval and General Motors puts

176
00:09:32,399 --> 00:09:38,159
it into a automotive factory to remove metal parts from

177
00:09:38,200 --> 00:09:41,039
a die caster. So a die caster is basically a

178
00:09:41,080 --> 00:09:44,919
big hydraulic ram. You put sheets of metal into it

179
00:09:44,960 --> 00:09:47,039
and it slams them into the shape of like a

180
00:09:47,080 --> 00:09:51,320
door panel. But that force that molds that that quickly

181
00:09:51,480 --> 00:09:54,799
makes the metal really HoTT. So not when a person

182
00:09:55,120 --> 00:09:57,080
has handled at any clubs and things, is very easy

183
00:09:57,120 --> 00:09:59,240
get burned like it's dangerous work. And so having the

184
00:09:59,320 --> 00:10:02,600
robot deal with that we made a lot of sense. Made sense. Yeah,

185
00:10:02,639 --> 00:10:05,600
And over the next decade or so, automation would come

186
00:10:06,080 --> 00:10:08,480
throughout the factory process. So it begins in sixty one

187
00:10:08,480 --> 00:10:11,480
with the Unimate. A little corollary to that, as they

188
00:10:11,480 --> 00:10:15,600
were celebrating the Unimate success, it got an appearance on

189
00:10:15,799 --> 00:10:18,320
Johnny Carson and poured a cup of coffee.

190
00:10:18,600 --> 00:10:21,759
Speaker 1: I think I do remember that. Yeah, yeah, it was

191
00:10:21,799 --> 00:10:24,519
ninety sixty one. You were not born yet, no, but

192
00:10:24,559 --> 00:10:27,440
I saw the rerun that was a famous famous clips.

193
00:10:27,200 --> 00:10:30,240
Speaker 2: Could be famous episode. Nineteen sixty one is also the

194
00:10:30,279 --> 00:10:36,759
first integrated circuit in production. Now I step into this

195
00:10:37,000 --> 00:10:41,720
very carefully because it is a hotly contested topic. In fact,

196
00:10:41,879 --> 00:10:45,200
it's got a Wikipedia entry just on the invention of

197
00:10:45,200 --> 00:10:48,240
the integrated circuit, because there's lots of arguments here. I mean,

198
00:10:48,320 --> 00:10:51,080
for I mean meaning who did it first? Yeah? And

199
00:10:51,120 --> 00:10:53,960
what represents an integrated circuit? Mean, we'd been messed around

200
00:10:53,960 --> 00:10:55,840
with semi conductors for a while, We've made a bunch

201
00:10:55,840 --> 00:10:59,240
of different kinds of transistors. You've got Back at fifty

202
00:10:59,240 --> 00:11:04,320
twosh radio engineer Jeffrey Dummer was making semiconductor circuits. There's

203
00:11:04,360 --> 00:11:10,360
also Harwick Johnson, Sydney Darlington, Yasatarui. But it really comes

204
00:11:10,360 --> 00:11:12,279
down to two people for the most I think most

205
00:11:12,320 --> 00:11:15,960
people agree. Now it's Jack Kilby of Texas Instruments with

206
00:11:16,080 --> 00:11:19,360
a thing he called the hybrid ice, so some discrete

207
00:11:19,399 --> 00:11:24,039
components and some integrated in a containerized package with pins,

208
00:11:24,600 --> 00:11:27,559
and of Robert Nois of Fairschald Semiconductor, who's also the

209
00:11:27,559 --> 00:11:30,399
guy who later goes on to form Intel with his

210
00:11:30,480 --> 00:11:31,519
monolithic ices.

211
00:11:31,799 --> 00:11:35,000
Speaker 1: So the integrated circuit means everything is on one ship

212
00:11:35,039 --> 00:11:38,759
with the pins and the transistors are mounted inside that.

213
00:11:38,759 --> 00:11:41,639
Speaker 2: That's the idea, and there's a bunch but if you're

214
00:11:41,639 --> 00:11:43,919
looking at just the packaging, So I have a package

215
00:11:43,919 --> 00:11:45,480
with pins on it, and it has a bunch of

216
00:11:45,519 --> 00:11:48,240
stuff in it, and it does a particular task that's

217
00:11:48,320 --> 00:11:53,320
pretty integrated. But then you get into what's actually inside

218
00:11:53,320 --> 00:11:56,600
that package, and you know, Noise is designed with what

219
00:11:56,600 --> 00:11:59,320
they call the monolithic icee is actually a layers of

220
00:12:00,039 --> 00:12:05,240
ustrate silicon crystal that are doped into different potentials so

221
00:12:05,279 --> 00:12:08,120
that they can be etched together to make transistors and

222
00:12:08,159 --> 00:12:11,240
resistors and other components. I get it. Yeah, Killey's approach

223
00:12:11,320 --> 00:12:12,320
was more discreete.

224
00:12:12,080 --> 00:12:16,000
Speaker 1: So ICs continued to evolve and get more powerful. But

225
00:12:16,120 --> 00:12:18,480
you're calling that one the first because it was the

226
00:12:18,519 --> 00:12:21,600
first contained integrated.

227
00:12:21,200 --> 00:12:24,159
Speaker 2: Well, I called the first really going in ninety sixty

228
00:12:24,200 --> 00:12:26,240
one is when it was first made into a product,

229
00:12:26,360 --> 00:12:30,799
at least briefly, and it was you know, the nexus

230
00:12:30,799 --> 00:12:34,200
of this is in two thousand, Jack Kilby was given

231
00:12:34,240 --> 00:12:37,440
the Nobel Prize in Physics for his quote unquote contributions

232
00:12:37,480 --> 00:12:40,279
integrated circuit and created a huge fuss around all that

233
00:12:40,320 --> 00:12:44,759
because Kilby's design that the hybrid icee doesn't last. Ultimately,

234
00:12:44,799 --> 00:12:47,720
Noises design is what makes integrated circuits to this day.

235
00:12:47,720 --> 00:12:50,720
Although limittedly. The technology has evolved a lot, but in

236
00:12:50,840 --> 00:12:56,720
nineteen sixty one, Texas Instruments started manufacturing a product called

237
00:12:56,759 --> 00:13:02,039
the Multivibrator five h two. Inside of that package, some

238
00:13:02,120 --> 00:13:05,519
of it some silicon substrates, some discrete were two transistors,

239
00:13:05,519 --> 00:13:08,960
four diode, six resistors, and two capacitors to be used

240
00:13:08,960 --> 00:13:12,720
as a waveform generator, which was part of a miniaturized

241
00:13:12,799 --> 00:13:16,039
radio receiver for the US Air Force. Wow. So they

242
00:13:16,080 --> 00:13:18,919
made a few hundred of these and built the test articles,

243
00:13:18,960 --> 00:13:21,720
and it ultimately failed, like in the end, it wasn't

244
00:13:21,720 --> 00:13:26,519
sturdy enough, but it set the big path for integrated

245
00:13:26,559 --> 00:13:28,759
circuits in that kind of ministriization at that time called

246
00:13:28,879 --> 00:13:33,000
molecular electronics because they were so small even though they

247
00:13:33,000 --> 00:13:36,679
were not molecule size in aerospace, and the Air Force

248
00:13:36,720 --> 00:13:38,639
would lead on this for quite a while. It leads

249
00:13:38,679 --> 00:13:41,279
to the ICBM and a bunch of other technology. But

250
00:13:41,480 --> 00:13:43,039
the first, you know, you can kind of hang your

251
00:13:43,080 --> 00:13:46,519
head on, Texas Instruments produce this first thing they called

252
00:13:46,559 --> 00:13:48,840
the integrated circuit, even though it was a design that

253
00:13:48,919 --> 00:13:52,000
ultimately fell into obsolescence in the model ethic ic would

254
00:13:52,000 --> 00:13:54,440
go on from there. Wow big one though, like I said,

255
00:13:54,480 --> 00:13:57,759
it's not simple. Yeah, it is.

256
00:13:57,720 --> 00:14:02,320
Speaker 3: Something simpler that we may all remember. Nineteen sixty one,

257
00:14:02,399 --> 00:14:06,840
Phillips introduced the audio cassette, the Compactus that we would

258
00:14:06,879 --> 00:14:11,559
all remember from compact cassette player from our Walkman's Wow

259
00:14:11,600 --> 00:14:12,639
throughout the eighties.

260
00:14:12,879 --> 00:14:15,960
Speaker 2: The Walkman's Walkman's is still twenty years away at that point.

261
00:14:16,000 --> 00:14:18,600
But yeah, I know, I know, but wow, you know

262
00:14:18,600 --> 00:14:20,000
what I you know, I pulled up a graphic on

263
00:14:20,039 --> 00:14:23,240
the other day on on the Nakamichi autocassett player because

264
00:14:23,240 --> 00:14:24,679
it was the one that would flip the tape. I

265
00:14:24,759 --> 00:14:25,159
have one.

266
00:14:25,399 --> 00:14:28,039
Speaker 1: It's right there. Actually, yeah, I have one. It doesn't

267
00:14:28,039 --> 00:14:30,120
work it, Yeah, flips the tape.

268
00:14:29,919 --> 00:14:32,120
Speaker 2: Over, pops the thing would pop out, turn the tape over,

269
00:14:32,159 --> 00:14:33,320
and go back because they didn't want to try and

270
00:14:33,320 --> 00:14:36,559
adjust the head alignments to play both both sides of

271
00:14:36,600 --> 00:14:37,240
the tape. You know.

272
00:14:37,840 --> 00:14:41,159
Speaker 1: Yeah, classics. Okay, all right, cool stuff. So I guess

273
00:14:41,279 --> 00:14:44,840
we can introduce Hannis officially. You've heard him talk there.

274
00:14:44,919 --> 00:14:49,639
But Hannis Lauette started his dot net career during college

275
00:14:49,679 --> 00:14:53,279
with Framework one point one. He continued this trend in

276
00:14:53,399 --> 00:14:55,720
his first jobs and has been using dot net ever

277
00:14:55,879 --> 00:15:00,000
since to deliver projects. For many different clients. He's always

278
00:15:00,000 --> 00:15:02,879
has had a passion for back end development in his projects.

279
00:15:02,919 --> 00:15:07,159
He's always gravitated to problems that involves scaling, architecture and complexity.

280
00:15:07,679 --> 00:15:09,879
Because of that, he developed a love for event driven

281
00:15:09,960 --> 00:15:13,840
architectures that fits with what we're going to talk about.

282
00:15:14,720 --> 00:15:19,399
Since twenty eleven, surprise, surprise, Yeah, yeah, Since twenty eleven,

283
00:15:19,440 --> 00:15:21,840
he's been working for ACES in Belgium.

284
00:15:21,919 --> 00:15:22,600
Speaker 2: Is that how you say it?

285
00:15:22,759 --> 00:15:28,919
Speaker 1: Yes, ax Xes currently as principal consultant. Aside from his

286
00:15:29,000 --> 00:15:32,399
technical role, Hannas has always been driven by helping other

287
00:15:32,480 --> 00:15:36,879
developers grow. He actively coaches people, runs workshops, gives conference talks,

288
00:15:37,440 --> 00:15:40,240
and is a course author on dome Train is free time.

289
00:15:40,279 --> 00:15:43,080
You can find him on stage playing guitar for line Breakers,

290
00:15:43,519 --> 00:15:47,159
The line Breakers, I guess that's the line Breaker Dylan's band.

291
00:15:47,320 --> 00:15:47,480
Speaker 2: Right.

292
00:15:47,919 --> 00:15:50,360
Speaker 1: When he's not doing things with his three children, he

293
00:15:50,440 --> 00:15:54,960
builds guitars, plays chess badly in parentheses, I didn't write this,

294
00:15:55,440 --> 00:15:59,960
and loves tasting whiskey and who doesn't to keep moving.

295
00:16:00,120 --> 00:16:03,039
He loves to mountain, bike or swim. All right, Hannas,

296
00:16:03,600 --> 00:16:06,759
The floor is All of those things are true. Wow, yeah,

297
00:16:07,360 --> 00:16:09,799
And the floor is yours. I'm sorry, I'm pretty sure

298
00:16:09,879 --> 00:16:10,519
you wrote this.

299
00:16:11,159 --> 00:16:13,639
Speaker 3: I'm just yeah, I kind I kind of sent this

300
00:16:13,879 --> 00:16:16,679
to Krawl in events. But hey, thanks for having me,

301
00:16:16,960 --> 00:16:19,879
Thanks for having show. I'm embarrassed almost that we haven't

302
00:16:19,879 --> 00:16:22,080
had you before at this point. Well, this is your

303
00:16:22,120 --> 00:16:24,360
first appearance on dot Ney Rocks, even though we've hung

304
00:16:24,440 --> 00:16:28,639
out at conferences and seen each other talk. Yeah many times.

305
00:16:29,039 --> 00:16:30,960
So welcome, Thank you, Thanks for having.

306
00:16:30,840 --> 00:16:34,360
Speaker 1: The floor is yours? You're going to talk about event sourcing.

307
00:16:34,679 --> 00:16:38,080
I guess maybe other things, maybe other shoes. Yeah, let's

308
00:16:38,080 --> 00:16:40,600
see where the conversation goes. Should we start with the

309
00:16:40,600 --> 00:16:43,000
elevator pitch? What is event sourcing? If you've been hiding

310
00:16:43,080 --> 00:16:44,879
under a rock for the last fifteen.

311
00:16:44,600 --> 00:16:50,879
Speaker 3: Years, okay, elevator pitch. We have been using systems like

312
00:16:50,960 --> 00:16:54,799
the default when we develop software systems seems to still

313
00:16:54,879 --> 00:17:00,200
be to use normalized databases. And basically, when you or

314
00:17:00,679 --> 00:17:04,680
state in a normalized database, what you're basically doing is

315
00:17:05,519 --> 00:17:09,200
storing the state of the system right now, and you

316
00:17:09,359 --> 00:17:12,799
lose all of the history that came before it. And

317
00:17:12,920 --> 00:17:16,119
with event sourcing, what we actually try to do is

318
00:17:16,279 --> 00:17:19,799
the opposite. We store all of the events that lead

319
00:17:20,440 --> 00:17:22,960
up to the current state, which means that if we

320
00:17:23,160 --> 00:17:26,839
replay the events, we can recalculate the state. If we

321
00:17:26,920 --> 00:17:31,400
have the state, we cannot recalculate the history because that's gone. Basically,

322
00:17:31,440 --> 00:17:35,640
if you switch your philosophy from storing state to storing events,

323
00:17:36,200 --> 00:17:39,319
you enable a whole lot of other things in your

324
00:17:39,519 --> 00:17:43,240
architectures as well. But the essence of event sourcing is

325
00:17:43,319 --> 00:17:46,440
basically that you're going to store events instead of the

326
00:17:46,559 --> 00:17:47,440
projected safe.

327
00:17:47,279 --> 00:17:50,039
Speaker 1: You neveric going to update, You're going to add a

328
00:17:50,160 --> 00:17:54,160
new record with the changes. Yes, some people have asked

329
00:17:54,200 --> 00:17:57,000
this by adding a couple of fields to every table.

330
00:17:57,200 --> 00:18:01,240
You know, update user and update date. You know, insert date,

331
00:18:01,359 --> 00:18:02,440
insert users.

332
00:18:02,200 --> 00:18:04,000
Speaker 3: Like auditing fields and stuff like.

333
00:18:04,160 --> 00:18:06,039
Speaker 1: Yeah, like auditing fields, and that's only good for the

334
00:18:06,119 --> 00:18:08,119
last change that was made.

335
00:18:08,519 --> 00:18:08,720
Speaker 2: Yeah.

336
00:18:10,559 --> 00:18:15,160
Speaker 3: The whole idea for me that makes this interesting is

337
00:18:15,279 --> 00:18:19,400
if we look at where database normalization comes from. A

338
00:18:19,480 --> 00:18:24,039
lot of that was conceived when the first Squel standards

339
00:18:24,119 --> 00:18:29,720
were developed in the nineteen eighties. And what's relevant for

340
00:18:30,000 --> 00:18:33,519
that time is that your average hard drive cost a

341
00:18:33,559 --> 00:18:36,799
lot more than the computer that it was attached to, Right,

342
00:18:37,279 --> 00:18:40,839
So normalizing had a couple of benefits. First of all,

343
00:18:41,079 --> 00:18:45,079
it made your data consistent and you try to avoid

344
00:18:45,279 --> 00:18:51,519
any update conflicts or any data manipulation concurrency issues that

345
00:18:51,599 --> 00:18:54,759
you might have. You would also store every bit of

346
00:18:54,920 --> 00:18:58,799
information only once, which conserved.

347
00:18:58,359 --> 00:19:01,920
Speaker 2: Disk space back back when that was important.

348
00:19:01,799 --> 00:19:04,480
Speaker 3: Right back when that was important. But nowadays on your

349
00:19:04,599 --> 00:19:08,160
cloud build, disk space is not typically the thing that

350
00:19:09,480 --> 00:19:15,920
most like CPU cycles and and memory usage and bandwidth

351
00:19:16,000 --> 00:19:18,000
like that's that's all going to be way more expensive

352
00:19:18,039 --> 00:19:19,480
than than your disk space.

353
00:19:19,920 --> 00:19:20,119
Speaker 2: Yeah.

354
00:19:20,440 --> 00:19:25,000
Speaker 3: But what we have, I think in our industry maybe

355
00:19:26,359 --> 00:19:28,480
ingrained in our brains a little bit, is all the

356
00:19:28,599 --> 00:19:32,079
tradeoffs that we've made to normalize our databases, because it

357
00:19:32,200 --> 00:19:35,279
comes with a whole bunch of tradeoffs, but we have

358
00:19:35,599 --> 00:19:39,240
just learned to work work around, right, all of those tradeoffs.

359
00:19:39,519 --> 00:19:43,680
Speaker 1: Sure, So what are those trade offs with normalized relational

360
00:19:43,759 --> 00:19:46,039
database that we might have forgotten about?

361
00:19:46,240 --> 00:19:50,599
Speaker 3: Well, the first thing that comes to mind is you

362
00:19:51,240 --> 00:19:55,400
are sacrificing CPU cycles to be able to store your

363
00:19:56,079 --> 00:19:59,720
data in a normalized shape, because whenever you have to

364
00:20:00,640 --> 00:20:03,400
fetch a meaningful amount of data to do work on,

365
00:20:03,519 --> 00:20:07,720
you're often hitting multiple tables, which means that you're doing joints,

366
00:20:08,799 --> 00:20:13,359
and joints are expensive. Yeah, and the problem with doing

367
00:20:13,480 --> 00:20:17,480
joints in a typical relational database is you also have

368
00:20:17,680 --> 00:20:21,960
no way of easily scaling that compute because it's going

369
00:20:22,039 --> 00:20:24,480
to happen in your database engine and you cannot just

370
00:20:24,640 --> 00:20:27,759
like put a cluster of nodes in front of it

371
00:20:27,880 --> 00:20:31,039
that are going to do the joints for you. So

372
00:20:31,200 --> 00:20:33,759
that's that's the first thing. You're sacrificing a bunch of

373
00:20:33,839 --> 00:20:40,519
compute to make that happen, and you introduce locking problems

374
00:20:41,480 --> 00:20:43,640
because whenever you touch your record, you have to make

375
00:20:43,680 --> 00:20:47,960
sure that there's no race conditions and no threading problems, so.

376
00:20:48,359 --> 00:20:51,240
Speaker 1: You have to use transactions in case there are problems,

377
00:20:51,279 --> 00:20:52,240
and then you roll it back.

378
00:20:52,359 --> 00:20:54,440
Speaker 3: Yeah, so either you're going to deal with that with

379
00:20:54,559 --> 00:20:57,759
optimistic concurrency or with pessimistic concurrency, but at some point

380
00:20:57,839 --> 00:21:01,279
you are going to deal with some kind of because

381
00:21:01,559 --> 00:21:04,400
concurrency issues that you're going to solve in your database

382
00:21:04,440 --> 00:21:08,279
as well, because you're only storing that one bit of state,

383
00:21:08,359 --> 00:21:10,359
and everybody that touches that is going to have to

384
00:21:10,440 --> 00:21:14,039
touch the same record and update it or deleted or whatever.

385
00:21:13,839 --> 00:21:14,640
Speaker 2: That we want to do with it.

386
00:21:15,839 --> 00:21:19,200
Speaker 3: And we've taken all of that for granted, because if

387
00:21:19,240 --> 00:21:22,039
we look at even the modern versions of dot Net.

388
00:21:22,200 --> 00:21:27,240
The first stack that they brought to Core included entity framework,

389
00:21:27,240 --> 00:21:31,279
and I'm a huge enity framework fan. But part of

390
00:21:31,599 --> 00:21:34,319
why we have or rems is because we try to

391
00:21:34,359 --> 00:21:36,839
solve some of the issues that you have with this

392
00:21:37,039 --> 00:21:40,920
way of thinking, because almost never are you in a

393
00:21:40,960 --> 00:21:44,359
complex application are you touching just a single table. You

394
00:21:44,519 --> 00:21:49,960
usually need a whole graph of different related tables, a

395
00:21:50,119 --> 00:21:54,240
parent entity with some with some related entities that you're

396
00:21:54,240 --> 00:21:56,480
all fetching and then updating and then writing back and

397
00:21:56,640 --> 00:21:58,480
all that sort of stuff. And that's why you have

398
00:21:58,839 --> 00:22:01,599
ORMs to make that a lot easier to do in code.

399
00:22:02,559 --> 00:22:05,519
But all of that is still working around the idea

400
00:22:05,640 --> 00:22:09,240
that we're only storing the truth at this very moment

401
00:22:09,440 --> 00:22:10,720
in our relational database.

402
00:22:11,680 --> 00:22:14,880
Speaker 2: And part of storing the truth is actually creating data

403
00:22:14,920 --> 00:22:17,599
structures that keep the truth. You know, the classic one

404
00:22:17,720 --> 00:22:22,440
is yes, only one address per customer, and then they move, Yeah.

405
00:22:22,440 --> 00:22:25,480
Speaker 3: Like you lose the history, Like what was the state

406
00:22:25,599 --> 00:22:30,400
of this entity last week, last year, or whatever. We've

407
00:22:30,480 --> 00:22:36,519
actually lost that. And that's where the whole idea of

408
00:22:37,000 --> 00:22:41,920
event sourcing comes from, is that if instead of storing

409
00:22:42,039 --> 00:22:47,559
the resulting state, we instead store all the business events

410
00:22:47,680 --> 00:22:50,920
that lead up to this state becoming what it is.

411
00:22:51,920 --> 00:22:54,240
We can always recreate the state because the state is

412
00:22:54,400 --> 00:22:56,680
just very cheaply replaying the events.

413
00:22:57,200 --> 00:22:57,319
Speaker 2: Right.

414
00:22:57,680 --> 00:23:00,799
Speaker 3: And in event sourcing, we assume that every event that

415
00:23:00,920 --> 00:23:05,240
we have written to our event stream what's true at

416
00:23:05,279 --> 00:23:07,279
the time that it was created, so we don't have

417
00:23:07,400 --> 00:23:10,519
to doubt it, right, this was the truth, which means

418
00:23:10,599 --> 00:23:13,839
that your replay mechanism is actually going to be relatively

419
00:23:13,960 --> 00:23:16,880
cheap because what you usually have is you have your

420
00:23:16,960 --> 00:23:19,519
root entity with all of its dependencies, and you're replaying

421
00:23:19,559 --> 00:23:23,119
all the events on that and you don't have to

422
00:23:23,200 --> 00:23:25,279
doubt the event. So a lot of these methods are

423
00:23:25,440 --> 00:23:28,079
just going to be setting a couple of fields, a

424
00:23:28,160 --> 00:23:30,359
couple of properties that you're going to fill out or

425
00:23:30,440 --> 00:23:34,079
modify or whatever, and you can replay thousands of events

426
00:23:34,359 --> 00:23:36,519
in just a couple of milliseconds. But the cool thing

427
00:23:36,559 --> 00:23:39,400
about that is that replaying is not happening in your

428
00:23:39,480 --> 00:23:43,759
database engine, is right. It's happening somewhere outside of it,

429
00:23:44,000 --> 00:23:46,640
in your net code, which is easier to distribute.

430
00:23:46,720 --> 00:23:48,640
Speaker 1: So the light bulb just went off because I was

431
00:23:48,680 --> 00:23:53,240
asking myself, when you're talking about the problems that it

432
00:23:53,400 --> 00:23:58,400
solves in this whole you know, multiple joints and everything. Well,

433
00:23:58,519 --> 00:24:01,960
now you're really kind of talking about flat document, right

434
00:24:02,240 --> 00:24:05,599
that instead of having all these joints. So is event

435
00:24:05,720 --> 00:24:10,319
sourcing something that you can use alongside a relational database,

436
00:24:10,480 --> 00:24:14,839
like your events are separate from the relational database? Or

437
00:24:15,880 --> 00:24:19,599
do you remove the hierarchy of a relational database when

438
00:24:19,599 --> 00:24:21,200
you're using events sourcing?

439
00:24:21,440 --> 00:24:26,000
Speaker 3: Well, typically what an event stream looks like is an

440
00:24:26,000 --> 00:24:31,160
append only store. You're going to append new events to

441
00:24:31,319 --> 00:24:33,880
the store, and all of these events happen usually in

442
00:24:33,960 --> 00:24:37,240
the scope of a certain stream ID or a certain

443
00:24:37,279 --> 00:24:39,160
aggregate I D or whatever you want to call it,

444
00:24:39,960 --> 00:24:45,000
which typically like what orders, it kind of points to

445
00:24:45,160 --> 00:24:48,359
the root and dy that this event happened for. Right,

446
00:24:48,559 --> 00:24:53,960
So if you have a certain order number, like customer

447
00:24:54,119 --> 00:24:57,799
Richard is placing an order on my website to order

448
00:24:58,039 --> 00:25:00,839
a new guitar, and he's going through the whole process

449
00:25:00,880 --> 00:25:02,599
of specking said.

450
00:25:02,440 --> 00:25:05,720
Speaker 2: Guitar, it'll be a tuba though for Richard, totally.

451
00:25:05,519 --> 00:25:13,519
Speaker 3: Totally hypothetical, and we could we could basically model Richard's

452
00:25:13,759 --> 00:25:16,920
configuration process of the guitar in multiple events. Now, he

453
00:25:17,000 --> 00:25:18,880
selected the color and he did this and he did

454
00:25:18,960 --> 00:25:22,400
that and whatever, and every event is going to point

455
00:25:22,480 --> 00:25:27,000
to Richard's order, which means that if you Carl at

456
00:25:27,039 --> 00:25:30,519
the same time are configuring a guitar as well, those

457
00:25:30,559 --> 00:25:34,440
two aggregates will have nothing that has that could potentially

458
00:25:34,599 --> 00:25:38,039
have a side effect on one another, because those will

459
00:25:38,119 --> 00:25:42,119
be two separate aggregates or two separate streams, if you will.

460
00:25:43,480 --> 00:25:46,720
And when we append everything to the store, we have

461
00:25:46,799 --> 00:25:49,200
a couple of things that play into the key. One

462
00:25:49,440 --> 00:25:52,720
is the aggregate that event happened for, but also the

463
00:25:52,799 --> 00:25:55,039
sequence number. And the sequence number is what's going to

464
00:25:55,079 --> 00:25:58,039
help us with concurrency, because at some point you're gonna

465
00:25:58,119 --> 00:26:00,799
have in an event source system, you're gonna want to

466
00:26:00,839 --> 00:26:03,559
scale out, you want to go You're gonna want to

467
00:26:03,599 --> 00:26:06,559
have a way to deal with multiple commands coming in

468
00:26:06,680 --> 00:26:10,000
on the same aggregate because they're all gonna spawn events

469
00:26:10,039 --> 00:26:12,400
on the same aggregate and you don't want them to

470
00:26:12,559 --> 00:26:17,160
be written to the database without knowing about the other

471
00:26:17,279 --> 00:26:20,519
events that might have happened in the mean one. So

472
00:26:20,720 --> 00:26:23,440
the the the stream idea or the aggregate idea, and

473
00:26:23,480 --> 00:26:25,519
the sequence number that's going to be the important bit

474
00:26:25,759 --> 00:26:29,079
of storing new events and events. The payload is just

475
00:26:29,200 --> 00:26:31,839
an object something that we serialize, and it could be

476
00:26:32,319 --> 00:26:35,000
several it could be as deep as we want, it

477
00:26:35,079 --> 00:26:37,960
could be a whole object graph. It's just a single

478
00:26:38,000 --> 00:26:40,799
object that we have to be able to de serialize again.

479
00:26:40,839 --> 00:26:43,359
And that's that's basically the essence of what you need.

480
00:26:43,839 --> 00:26:45,440
Simplest event stream you could build.

481
00:26:45,759 --> 00:26:49,440
Speaker 1: So let's say the first person to log on after midnight. Right,

482
00:26:50,039 --> 00:26:53,400
Let's say you're going to get all the data from

483
00:26:53,440 --> 00:26:57,160
your relational database, et cetera and make an event that's like, hey,

484
00:26:57,279 --> 00:26:58,519
this is the first event today.

485
00:27:00,400 --> 00:27:00,559
Speaker 2: Is that?

486
00:27:00,799 --> 00:27:03,119
Speaker 1: Is that the idea, and then all the modifications that

487
00:27:03,240 --> 00:27:05,799
happen to it just work with that those event streams

488
00:27:06,359 --> 00:27:08,599
and when you when you're doing updates and everything.

489
00:27:08,759 --> 00:27:12,400
Speaker 3: No, the idea is that the idea is that if

490
00:27:12,519 --> 00:27:16,880
you need that root entity, instead of fetching that from

491
00:27:16,920 --> 00:27:20,240
the database, you were actually going to fetch all of

492
00:27:20,279 --> 00:27:24,680
the events that have happened on that entity and then

493
00:27:24,759 --> 00:27:27,000
you're going to replay them in code. Okay, and that

494
00:27:27,079 --> 00:27:29,200
will bring you up to speed to the point where

495
00:27:29,240 --> 00:27:30,880
we are. But where do we start? I mean we

496
00:27:31,000 --> 00:27:33,240
start with a database, right that has on a data

497
00:27:33,279 --> 00:27:36,079
in it. Yeah, well, you could know your database could

498
00:27:36,240 --> 00:27:38,920
just be a single table with all of your events

499
00:27:38,960 --> 00:27:39,079
in it.

500
00:27:39,279 --> 00:27:41,440
Speaker 2: Oh all right, so this is what I was asking before.

501
00:27:41,960 --> 00:27:46,440
Speaker 1: You get rid of your relational database in but you

502
00:27:46,559 --> 00:27:50,359
still have your objects in memory, right. You define your

503
00:27:50,400 --> 00:27:53,880
memory that you're going to turn into Jason yes in

504
00:27:54,000 --> 00:27:55,759
story in your event database.

505
00:27:55,640 --> 00:27:58,920
Speaker 3: Whenever the live cycle of how, let's say, an API

506
00:27:59,039 --> 00:28:01,480
call comes in. I think that's the easiest way to

507
00:28:01,839 --> 00:28:05,319
reason about. It's like an API call comes in typically

508
00:28:05,400 --> 00:28:08,519
a command something you want your system to do, and

509
00:28:08,640 --> 00:28:11,119
you're going to want to execute that. Usually your commands

510
00:28:11,119 --> 00:28:14,160
are going to touch a certain root entity. If I'm

511
00:28:14,200 --> 00:28:17,680
going to update the address for Carl, the root entity

512
00:28:17,799 --> 00:28:19,279
is going to be Carl, right, So I'm going to

513
00:28:19,319 --> 00:28:22,880
have to fetch your date details, and then your current

514
00:28:23,000 --> 00:28:25,720
state is going to dictate what the result of the

515
00:28:25,759 --> 00:28:28,240
command is going to be, because what your current address

516
00:28:28,720 --> 00:28:31,920
is might affect what happens with this address update. So

517
00:28:32,079 --> 00:28:34,160
in order to get your current state, I'm going to

518
00:28:34,200 --> 00:28:36,880
fetch all of the events that have happened on entity Carl,

519
00:28:37,400 --> 00:28:40,559
replay them, get your current state, then run my command,

520
00:28:40,640 --> 00:28:42,720
and then append the new events to the stream.

521
00:28:42,759 --> 00:28:44,640
Speaker 2: Again. Yep, I get that. I get that.

522
00:28:44,799 --> 00:28:47,559
Speaker 1: I guess what I didn't get was that we're completely

523
00:28:47,680 --> 00:28:51,759
replacing our relational database well in this with a document

524
00:28:52,039 --> 00:28:53,720
centric database.

525
00:28:53,400 --> 00:28:58,720
Speaker 3: For the events sourced stuff. Yes, yes, And what does

526
00:28:58,920 --> 00:29:02,279
happen a lot is that you will still have relational

527
00:29:02,400 --> 00:29:05,160
tables with some reference data and so on. There's no

528
00:29:05,519 --> 00:29:11,119
point in making every single entity in your entire system

529
00:29:11,240 --> 00:29:13,759
events sourced. I mean, you don't want to hurt yourself

530
00:29:13,839 --> 00:29:16,799
too much. And so if you have a table that

531
00:29:17,079 --> 00:29:20,720
just has a list of countries or whatever, you could

532
00:29:20,799 --> 00:29:22,839
make that event sourced if that is part of your

533
00:29:22,920 --> 00:29:26,759
core domain. Usually that kind of stuff is reference data

534
00:29:26,799 --> 00:29:30,799
and you can just keep that in relational tables. But

535
00:29:30,960 --> 00:29:33,519
when it comes to the entities where you're doing you're

536
00:29:33,559 --> 00:29:37,759
running your actual domain logic, you're going to basically want

537
00:29:38,039 --> 00:29:41,720
to get your truth from the events. That's the whole idea.

538
00:29:42,039 --> 00:29:43,960
Speaker 1: Yeah, that's great, and this is a great place to

539
00:29:44,039 --> 00:29:46,480
pause for a break, So we'll be right back after

540
00:29:46,559 --> 00:29:51,160
these very important messages don't go away. Did you know

541
00:29:51,279 --> 00:29:54,640
you can easily migrate asp net web apps to Windows

542
00:29:54,720 --> 00:29:59,119
containers on AWS. Use the app to Container tool to

543
00:29:59,279 --> 00:30:02,960
container eye is your iis websites and deployed to AWS

544
00:30:03,160 --> 00:30:08,240
managed container services with or without Kubernetes. Find out more

545
00:30:08,240 --> 00:30:12,880
about app to container at aws dot Amazon dot Com, slash,

546
00:30:12,960 --> 00:30:19,960
dot net, slash modernize, and we're back. It's dot net Rocks.

547
00:30:20,000 --> 00:30:22,680
I'm Carl Franklin, an amateur Campbell, and we're talking to

548
00:30:22,759 --> 00:30:24,720
Hanness Lowett about event sourcing.

549
00:30:25,039 --> 00:30:28,319
Speaker 2: You know, I'm reminded that the relational Databases developer reporting

550
00:30:29,000 --> 00:30:31,839
and it got sold on transactional velocity because that was

551
00:30:31,839 --> 00:30:35,400
easier to sell. But there is a there's a case

552
00:30:35,440 --> 00:30:38,960
to be made for after an event is logged, if

553
00:30:39,039 --> 00:30:41,279
you think it's reportable or it's a you know, falls

554
00:30:41,279 --> 00:30:44,039
in a certain class of event, then you do decompose

555
00:30:44,119 --> 00:30:48,400
it asynchronously, not making the customer way into relational data

556
00:30:48,480 --> 00:30:51,160
tables for reporting purposes, because.

557
00:30:51,000 --> 00:30:53,759
Speaker 3: That's what we call projections. Yeah, and so what you

558
00:30:53,880 --> 00:30:58,799
basically do if you think about your c qres architecture,

559
00:30:58,880 --> 00:31:00,640
Let's say that you have a comment side of your

560
00:31:00,720 --> 00:31:03,799
system where all of the business logics is triggered when

561
00:31:04,880 --> 00:31:08,079
other systems or users Q commands, and you have your

562
00:31:08,160 --> 00:31:12,359
red side of the system where you're querrying data. It

563
00:31:12,559 --> 00:31:17,519
makes sense to prepare some data for querying because if

564
00:31:17,559 --> 00:31:21,559
you regularly need to pull a list of all of

565
00:31:21,640 --> 00:31:24,759
your customers with their current addresses. That's going to be

566
00:31:24,960 --> 00:31:27,599
very expensive to run if you have to project it

567
00:31:27,680 --> 00:31:30,559
from the source events, because what you're basically going to

568
00:31:30,640 --> 00:31:33,799
have to do is get all of your users and

569
00:31:33,920 --> 00:31:36,240
project them all one by one until you have the

570
00:31:36,319 --> 00:31:40,000
list of addresses. As way too expensive. So basically, whenever

571
00:31:40,240 --> 00:31:46,880
we queue, whenever we save an address changed event, that's

572
00:31:46,920 --> 00:31:50,160
going to update that table. So we have little bit

573
00:31:50,279 --> 00:31:52,519
of bits of business logic that are going to be

574
00:31:52,720 --> 00:31:59,200
running and listening to certain events and then updating projected tables. Now,

575
00:31:59,279 --> 00:32:01,839
the big advantage of doing that is that also that

576
00:32:02,279 --> 00:32:06,400
is relatively inexpensive. You can look at the contents of

577
00:32:06,480 --> 00:32:08,759
your event and you know, okay, it's this entity. This

578
00:32:08,920 --> 00:32:11,599
is talking about Carl, and Carl has new address. So

579
00:32:11,640 --> 00:32:14,400
all I have to do is without really thinking, because

580
00:32:14,400 --> 00:32:16,240
I don't have to check the validity of the event

581
00:32:16,359 --> 00:32:19,839
that has happened when we executed command, so I don't

582
00:32:19,880 --> 00:32:22,359
have to recheck that. I can just take that and

583
00:32:22,440 --> 00:32:25,920
then update the view or at the table that we

584
00:32:26,039 --> 00:32:28,359
are going to querry on the query side of our system,

585
00:32:28,440 --> 00:32:31,000
and we can keep that in sync. And the cool

586
00:32:31,079 --> 00:32:34,279
thing about these projections is if we want, we can

587
00:32:34,440 --> 00:32:38,720
rebuild them so whenever the logic to go from source

588
00:32:38,839 --> 00:32:42,480
events to whatever projected data we want to have. Whenever

589
00:32:42,640 --> 00:32:46,799
that changes, we just throw away the table and repopulate it.

590
00:32:46,880 --> 00:32:51,079
We replay the stream from the beginning of time and like,

591
00:32:51,240 --> 00:32:54,640
if you have a system with millions and millions of events, like,

592
00:32:54,759 --> 00:32:57,400
some of these projections might take a while to rebuild,

593
00:32:57,480 --> 00:33:00,880
so there are techniques to do that at a synchroncy

594
00:33:01,079 --> 00:33:05,000
before you replace the table, that sort of stuff. But

595
00:33:05,160 --> 00:33:09,720
you can basically get an updated view of your query

596
00:33:09,880 --> 00:33:12,839
data by just rerunning the events and replaying them because

597
00:33:12,839 --> 00:33:15,799
you still have everything that has happened in the system

598
00:33:15,960 --> 00:33:16,480
ever since.

599
00:33:16,720 --> 00:33:19,039
Speaker 2: Yeah, so it means you could always regenerate any aggregate

600
00:33:19,319 --> 00:33:21,759
resulting data set one or the other at least validate

601
00:33:21,799 --> 00:33:24,519
whether it's correct or not. But my concern is as

602
00:33:24,559 --> 00:33:26,519
your number of events starts to build up, finding out

603
00:33:26,599 --> 00:33:28,960
how many orders did we have last month can get costly.

604
00:33:29,200 --> 00:33:32,240
Speaker 3: Well, not if you have a projection that updates that

605
00:33:32,519 --> 00:33:36,519
view on the floor right right. If your projection is

606
00:33:36,640 --> 00:33:39,400
caught up and you're not changing the way that that

607
00:33:39,519 --> 00:33:43,440
projection works. Theory, you should not have to rebuild it.

608
00:33:43,599 --> 00:33:45,079
Speaker 2: So it should always be correct.

609
00:33:45,559 --> 00:33:49,319
Speaker 3: It should always be correct, So you can you can

610
00:33:49,400 --> 00:33:52,200
flip this around. You could have a projection for every

611
00:33:52,359 --> 00:33:55,720
query endpoint on your querry API that hits a single

612
00:33:55,799 --> 00:33:58,440
table on an index, and you can have that table

613
00:33:58,519 --> 00:34:02,480
populated from your event stream with a dedicated projection just

614
00:34:02,559 --> 00:34:03,200
for that table.

615
00:34:03,680 --> 00:34:07,359
Speaker 2: But I appreciate that we're both saying should because things

616
00:34:07,440 --> 00:34:10,159
do go wrong, but can also be fixed.

617
00:34:10,360 --> 00:34:12,719
Speaker 3: Of course, it can be fixed, and that's that's the

618
00:34:12,760 --> 00:34:17,599
big advantage. Because you have the whole history, you you

619
00:34:17,880 --> 00:34:22,199
can rebuild anything. And in theory, like one of the

620
00:34:22,280 --> 00:34:24,960
examples that's often used is okay, you can you can

621
00:34:25,119 --> 00:34:29,599
generate new insights from past events. And in theory that's

622
00:34:29,719 --> 00:34:32,039
true if you have saved all of the events, you

623
00:34:32,119 --> 00:34:36,960
can basically generate new insights, new features, even based on

624
00:34:37,039 --> 00:34:39,119
events that have happened in the past, and you can

625
00:34:39,239 --> 00:34:42,719
repopulate the view by just letting that projection run until

626
00:34:42,760 --> 00:34:47,679
it's caughta In practice, like often when you're extending a

627
00:34:47,719 --> 00:34:51,079
feature set of an application, you're also introducing new events

628
00:34:51,480 --> 00:34:56,440
and you will not taken those into account in the past,

629
00:34:56,559 --> 00:35:01,760
so it that that claim has a limited validity. In practice,

630
00:35:03,000 --> 00:35:04,480
but it's a cool selling point, right.

631
00:35:04,599 --> 00:35:07,480
Speaker 1: Yeah. So you've been talking about some of the problems

632
00:35:07,559 --> 00:35:11,679
that have event sourcing solves. Are there any new challenges

633
00:35:11,760 --> 00:35:15,559
with event sourcing that come into plug.

634
00:35:15,440 --> 00:35:21,840
Speaker 3: Oh, definitely, some of some of the challenges that, weirdly,

635
00:35:21,960 --> 00:35:25,280
you don't have with a normalized database because if you

636
00:35:26,119 --> 00:35:31,599
normalize your database properly, every bit of information is one

637
00:35:32,360 --> 00:35:34,480
linked to the primary key of the table that it's in,

638
00:35:35,039 --> 00:35:38,840
and it's only stored in one bit. So if you

639
00:35:38,880 --> 00:35:41,159
do it right, you should end up with a pretty

640
00:35:41,639 --> 00:35:45,079
deterministic view of what your data looks like and the

641
00:35:45,159 --> 00:35:47,320
way that you query it and update it on whatever.

642
00:35:47,480 --> 00:35:47,519
Speaker 2: Like.

643
00:35:47,599 --> 00:35:50,000
Speaker 3: All of that is coding that happens afterward, so you

644
00:35:50,119 --> 00:35:54,519
don't have to think about that too much. As soon

645
00:35:54,599 --> 00:35:59,840
as you start applying event sourcing, partitioning your system based

646
00:36:00,119 --> 00:36:03,079
on the root entity that the commands are going to

647
00:36:03,119 --> 00:36:07,559
happen in basically determining the boundaries of your aggregates, that

648
00:36:07,760 --> 00:36:11,119
becomes very important. But it's a problem that you also

649
00:36:11,320 --> 00:36:15,440
see when you use a document database. For instance, if

650
00:36:15,480 --> 00:36:20,519
you switched over to something like the dB or AVNDB

651
00:36:20,679 --> 00:36:23,519
or whatever, you're going to see the same problem because

652
00:36:23,559 --> 00:36:26,079
you have to really think about which bit of my

653
00:36:26,239 --> 00:36:31,360
data belongs together and is a sensible scope to process commands.

654
00:36:31,480 --> 00:36:33,559
Because as soon as you have to start working with

655
00:36:33,679 --> 00:36:36,599
multiple documents and multiple streams at the same time, that's

656
00:36:36,679 --> 00:36:39,000
when things get tricky, right, But.

657
00:36:39,119 --> 00:36:41,920
Speaker 1: Generally you know what those things are, right, I mean,

658
00:36:42,039 --> 00:36:45,000
you generally have to find the tip of the iceberg

659
00:36:45,719 --> 00:36:48,440
and then you know all the related data goes in

660
00:36:48,519 --> 00:36:52,480
there as well. So isn't that's something that you would

661
00:36:52,519 --> 00:36:55,000
probably know if you're familiar with the data shape.

662
00:36:55,119 --> 00:37:00,519
Speaker 3: If you're familiar with the data shape, yes, But fromans,

663
00:37:01,079 --> 00:37:06,199
I feel like most developers that come from the crut

664
00:37:07,199 --> 00:37:12,599
normalized database world they don't think that way and they've

665
00:37:12,679 --> 00:37:15,480
never actually wondered like, which are my root entities?

666
00:37:15,760 --> 00:37:17,360
Speaker 2: Where does the stuff happen?

667
00:37:18,159 --> 00:37:22,960
Speaker 3: And as soon as you start mapping out business processes

668
00:37:23,840 --> 00:37:26,320
and you start thinking about what is happening here in

669
00:37:26,440 --> 00:37:29,639
my business? When does a user or an external system

670
00:37:29,760 --> 00:37:32,840
q a command? What is happening when that command? Which

671
00:37:33,039 --> 00:37:35,920
entity does that command hit? That's when all of that

672
00:37:36,119 --> 00:37:40,000
becomes very clear. So if you practice things like domain

673
00:37:40,079 --> 00:37:43,719
driven design and you start using things like even storming

674
00:37:43,880 --> 00:37:47,280
to map out your business processes. With post its on

675
00:37:47,360 --> 00:37:51,320
a wall, you end up with not only a very

676
00:37:51,400 --> 00:37:54,519
clear view of how you're going to partition that system,

677
00:37:54,639 --> 00:37:56,840
but you end up with post its that you can

678
00:37:57,079 --> 00:38:00,760
one on one basically convert into class in code, because

679
00:38:00,800 --> 00:38:02,960
those will become your commands and your events and all

680
00:38:03,000 --> 00:38:06,039
of that. And of course there's there's work to do,

681
00:38:07,039 --> 00:38:07,519
but at.

682
00:38:07,480 --> 00:38:09,199
Speaker 2: Least the the.

683
00:38:11,239 --> 00:38:15,000
Speaker 3: Amount of information that can get lost when you try

684
00:38:15,079 --> 00:38:18,519
to translate that from that wideboard full of post its

685
00:38:18,559 --> 00:38:21,599
into code is a lot closer than it would be

686
00:38:21,760 --> 00:38:25,000
if you're using a relational database. It also will have

687
00:38:25,360 --> 00:38:26,760
way less side effects.

688
00:38:27,000 --> 00:38:29,239
Speaker 1: So if you have if you create your what you

689
00:38:29,360 --> 00:38:33,199
think is your hierarchy and your your your shape and

690
00:38:33,280 --> 00:38:37,239
your root unit down and you start saving some events

691
00:38:37,280 --> 00:38:39,679
and all that stuff, and then you realize, oh, I

692
00:38:39,800 --> 00:38:44,559
need this entity in here as well. Does that change

693
00:38:44,599 --> 00:38:47,599
anything or do those past events become invalid or in

694
00:38:47,679 --> 00:38:49,920
the new event you've just added this entity.

695
00:38:50,440 --> 00:38:56,480
Speaker 3: And not really like there are definitely scenarios where you

696
00:38:56,599 --> 00:39:02,360
are going to touch multiple multiple streams as a result

697
00:39:02,440 --> 00:39:05,440
of a single command. Think about your shopping car, for instance,

698
00:39:05,480 --> 00:39:07,960
at some point you're also going to touch the stock system,

699
00:39:09,039 --> 00:39:12,199
so that might be another stream that lives in the

700
00:39:12,280 --> 00:39:17,159
same application. That might be an external system that needs

701
00:39:17,199 --> 00:39:18,920
to get called, right, so.

702
00:39:19,000 --> 00:39:21,440
Speaker 1: You're not trying to make one stream that rules them all.

703
00:39:22,559 --> 00:39:25,880
This is what you're talking about boundaries having where do

704
00:39:25,920 --> 00:39:28,119
you separate those things exactly?

705
00:39:28,199 --> 00:39:30,840
Speaker 3: And you have to figure out where the boundaries are

706
00:39:31,079 --> 00:39:35,880
and cross them with a very conscious state of mind.

707
00:39:35,960 --> 00:39:39,639
I have to worry about where am I leaving, like

708
00:39:39,760 --> 00:39:41,519
the thing that I can do on a single stream,

709
00:39:42,360 --> 00:39:45,000
and there has to be a very good reason for that. Like,

710
00:39:45,119 --> 00:39:47,880
if all of your commands are doing that, then you

711
00:39:48,079 --> 00:39:49,480
model something really wrong.

712
00:39:50,679 --> 00:39:53,079
Speaker 2: Yeah, I think single stream for everything is bad too,

713
00:39:53,199 --> 00:39:55,039
but I'm sure you end up with arguments about too

714
00:39:55,079 --> 00:39:55,719
many streams.

715
00:39:56,679 --> 00:40:00,199
Speaker 3: So the like, there's a couple of patterns that you

716
00:40:00,280 --> 00:40:03,239
can use. For instance, like the saga pattern is very

717
00:40:03,320 --> 00:40:06,920
well known. If you have a command that comes into

718
00:40:06,960 --> 00:40:09,920
your system that's going to touch multiple streams or even

719
00:40:10,000 --> 00:40:12,800
multiple systems if you have to make external calls, what

720
00:40:12,960 --> 00:40:17,920
you typically have is a quite long running transaction that

721
00:40:18,079 --> 00:40:20,960
is going to be happening as soon as that command

722
00:40:21,039 --> 00:40:24,480
comes in, right, So you're going to save some intermediary

723
00:40:24,559 --> 00:40:28,320
states and let the whole thing play out because with

724
00:40:28,480 --> 00:40:31,320
external systems, it might be an outgoing call and then

725
00:40:31,360 --> 00:40:33,280
a callback coming in and whatever you're going to have

726
00:40:33,360 --> 00:40:35,280
to be able to pick up the threat. That's a

727
00:40:35,360 --> 00:40:39,840
perfect way to model that, and it's not that dissimilar

728
00:40:40,000 --> 00:40:44,280
from how you model more complex transactions across multiple streams

729
00:40:45,000 --> 00:40:50,679
and inside the system. Now if you use frameworks, because

730
00:40:50,719 --> 00:40:53,559
a lot of it depends on what is backing your

731
00:40:55,559 --> 00:40:58,119
what is backing your event sourcing framework, Like you can

732
00:40:58,239 --> 00:41:00,079
roll your own. A lot of it is not that

733
00:41:00,239 --> 00:41:04,519
complex and you needed probably about a day to to

734
00:41:05,039 --> 00:41:10,239
roll something that can do a lot of the things

735
00:41:10,760 --> 00:41:12,840
if you want to have something battle tested and let

736
00:41:12,920 --> 00:41:15,519
somebody else think about hard work. You've had Jeremy on

737
00:41:15,599 --> 00:41:19,960
the show and we talked about Martin his Martin framework

738
00:41:20,280 --> 00:41:23,960
is well, it's not is it a framework or a

739
00:41:24,039 --> 00:41:27,800
document database? It's an event store right right? What Martin

740
00:41:28,079 --> 00:41:31,320
calls it a web framework. Yeah, well that's that's if

741
00:41:31,360 --> 00:41:34,320
you involve Wolverine and and and all the other things

742
00:41:34,360 --> 00:41:41,079
of the Critter, Critter Stack, the creator. But Martin Martin

743
00:41:41,199 --> 00:41:45,639
is basically I don't know if that's my story to tell.

744
00:41:45,800 --> 00:41:47,719
I'm sure Jeremy told it on the show.

745
00:41:47,519 --> 00:41:49,400
Speaker 2: As well, Like he's been on a few times.

746
00:41:49,800 --> 00:41:52,679
Speaker 3: They they ran into trouble with with raven dB, if

747
00:41:52,719 --> 00:41:55,880
I remember correctly, and they needed something capable of handling

748
00:41:55,920 --> 00:41:58,039
the load, and they looked at postcrests. It's like, cool,

749
00:41:58,079 --> 00:41:59,920
Postcrest can do a lot of stuff that we need

750
00:42:00,039 --> 00:42:03,079
when it comes to the document stuff, but the projection

751
00:42:03,199 --> 00:42:06,400
stuff that's in raven like not so much. And that's

752
00:42:06,440 --> 00:42:09,960
why they ended up building a lot of what Martin

753
00:42:10,199 --> 00:42:13,519
eventually became. And because that had documents in there and

754
00:42:13,639 --> 00:42:17,400
had projections in there like, it became a very nice

755
00:42:17,519 --> 00:42:21,719
candidate for building an event source system as well, because

756
00:42:21,760 --> 00:42:25,159
if you have a stream with all your documents that

757
00:42:25,519 --> 00:42:27,840
have all of your events that have happened in the past,

758
00:42:28,719 --> 00:42:31,760
and you can run projections on that, then you're already

759
00:42:32,079 --> 00:42:34,159
like eighty percent of the way there to have an

760
00:42:34,199 --> 00:42:37,519
event source system where you have your event stream and

761
00:42:37,599 --> 00:42:40,199
you have your projections that project into other documents or

762
00:42:40,239 --> 00:42:44,079
other tables or whatever, which is why Martin now has

763
00:42:44,079 --> 00:42:48,800
a very explicit support for event sourcing, and you get

764
00:42:48,840 --> 00:42:50,760
an out of the box event stream that you can

765
00:42:51,000 --> 00:42:54,239
pentax to and it supports all the things that you

766
00:42:54,400 --> 00:42:59,360
will run run into at first when you start growing

767
00:42:59,480 --> 00:43:01,960
one of these systems, because one of the typical problems

768
00:43:02,039 --> 00:43:05,159
is you have a certain aggregate that becomes very long

769
00:43:05,239 --> 00:43:08,880
lived and it starts accumulating not thousands, but millions of

770
00:43:08,960 --> 00:43:13,039
events that becomes very expensive to replay. So at some

771
00:43:13,159 --> 00:43:15,599
point you're going to want to start snapshotting that. Right,

772
00:43:15,719 --> 00:43:18,679
We're going to take a snapshot at events one million,

773
00:43:18,840 --> 00:43:20,920
two hundred and sixty four so that we only have

774
00:43:21,039 --> 00:43:26,559
to replay the last fifty, right, and all of that

775
00:43:26,760 --> 00:43:31,599
functionality is already built in. Somebody has thought about that way,

776
00:43:31,960 --> 00:43:34,880
about those things way harder than most of us ever will,

777
00:43:35,639 --> 00:43:38,960
And I think that's a very valid argument to start

778
00:43:39,159 --> 00:43:43,440
using one of those ready made frameworks to do that

779
00:43:43,800 --> 00:43:46,159
kind of stuff. But you do have to understand what

780
00:43:46,400 --> 00:43:50,000
goes on behind the scenes, because if you register a

781
00:43:50,079 --> 00:43:54,760
projection in there, that's going to spin off a background

782
00:43:54,880 --> 00:43:57,639
worker that's actually going to be querrying your database and

783
00:43:57,760 --> 00:44:00,639
running code and writing back to the database. So none

784
00:44:00,679 --> 00:44:03,480
of that's it happens magically, but it's not.

785
00:44:03,599 --> 00:44:05,599
Speaker 2: Free, right. Yeah. I was just going back and look

786
00:44:05,639 --> 00:44:07,559
at the Jerry Miller shows and realized the entire thing

787
00:44:07,639 --> 00:44:09,960
that you've just told we've done as a series of

788
00:44:10,000 --> 00:44:13,440
shows with him about Martin on Postgrass, then playing with

789
00:44:13,559 --> 00:44:18,920
events sourcing, and then Wolverine, and it's literally working through

790
00:44:19,000 --> 00:44:22,199
the problems you're describing as this works up to this

791
00:44:22,320 --> 00:44:23,960
point and then you need to go over here and

792
00:44:24,159 --> 00:44:25,320
like it's just it's.

793
00:44:25,320 --> 00:44:28,400
Speaker 3: Yeah, Wolverine is very nice SAGA support, right, So if

794
00:44:28,440 --> 00:44:30,800
you pair that with Martin, that works really well.

795
00:44:30,920 --> 00:44:35,519
Speaker 2: Now we're back in the critter stack exactly. There's a

796
00:44:35,599 --> 00:44:37,519
reason that we have all these different critters.

797
00:44:37,800 --> 00:44:40,400
Speaker 3: Yeah, But like I think at this moment in the

798
00:44:40,480 --> 00:44:44,320
dot net space, Martin is probably one of the one

799
00:44:44,360 --> 00:44:47,159
of the best ways to get started with events sourcing

800
00:44:47,639 --> 00:44:49,679
because you get a lot of stuff out of the

801
00:44:49,760 --> 00:44:54,079
box and the complexity of the setup for you as

802
00:44:54,239 --> 00:45:00,239
the person developing the system, the complexity is relative fully

803
00:45:00,320 --> 00:45:02,639
low because what you need is a dot net process

804
00:45:02,800 --> 00:45:05,960
that connects to a postcress database, right, and if you

805
00:45:06,079 --> 00:45:10,840
have multiple nodes doing that, they will actually communicate through

806
00:45:11,440 --> 00:45:15,360
postcress locks, so you don't need anything out of band

807
00:45:16,159 --> 00:45:19,559
for your notes to make sure that they're not interfering

808
00:45:19,639 --> 00:45:20,320
with one another.

809
00:45:20,519 --> 00:45:23,119
Speaker 2: What makes postcrests special in this situation, Like I I

810
00:45:23,119 --> 00:45:25,840
already have SQL server why wouldn't I use it basin

811
00:45:26,400 --> 00:45:28,599
binary chasin binary Jason.

812
00:45:28,360 --> 00:45:33,239
Speaker 1: Okay, no, well SQL server has adjacent table field type now, yeah,

813
00:45:33,679 --> 00:45:34,559
but it's more expensive.

814
00:45:34,679 --> 00:45:38,519
Speaker 3: Yeah, but for a long time they didn't. And postcress

815
00:45:38,599 --> 00:45:42,000
is is still a lot more powerful than what the

816
00:45:42,360 --> 00:45:43,199
server is trying.

817
00:45:43,360 --> 00:45:46,079
Speaker 2: I also like the licensing on postgrass, which is to

818
00:45:46,239 --> 00:45:49,960
say free. Yeah, but.

819
00:45:51,840 --> 00:45:56,199
Speaker 3: Postcress is ridiculously powerful and it does a lot of

820
00:45:56,360 --> 00:46:00,480
things very well. And Basin is basically a way that

821
00:46:00,679 --> 00:46:04,159
they figured out to store chasing documents in a binary

822
00:46:04,280 --> 00:46:07,599
format in a way that they could still index on

823
00:46:08,400 --> 00:46:15,400
fields that are pretty deep in the document's tree, which

824
00:46:15,480 --> 00:46:21,000
is cool. Added benefit is this works in an acid

825
00:46:21,320 --> 00:46:26,480
transactional database, which Mongo. In Mongo, for instance, you have

826
00:46:28,320 --> 00:46:32,800
transactions on document level, but not across multiple documents. And

827
00:46:32,960 --> 00:46:36,480
with postgress, that's a thing that's there by default because

828
00:46:37,360 --> 00:46:40,880
by default it's an ASTE compliant relational database. And because

829
00:46:41,360 --> 00:46:44,320
basin is so powerful, like in a lot of scenarios,

830
00:46:44,960 --> 00:46:48,760
it will outperform a lot of other document databases while

831
00:46:49,519 --> 00:46:54,159
basically being a relational database. And I get the irony, like,

832
00:46:54,320 --> 00:46:56,800
now we're going to use a relational database to store

833
00:46:56,880 --> 00:46:58,599
our events stream and our documents.

834
00:46:59,360 --> 00:47:01,079
Speaker 1: But you know, but at the same time you get

835
00:47:01,159 --> 00:47:03,000
the relational stuff you need that too, So.

836
00:47:03,320 --> 00:47:05,760
Speaker 3: Yes, and and that's one of the cool things. If

837
00:47:05,800 --> 00:47:09,639
you want to project your events into actual sequel tables,

838
00:47:09,840 --> 00:47:13,920
like you can do that in the same transactions. You

839
00:47:14,000 --> 00:47:17,679
will be able to run if you want. You can

840
00:47:17,800 --> 00:47:21,239
have some of your projections transactionally consistent, meaning that they

841
00:47:21,280 --> 00:47:24,760
will project when you're saving the event. Like that's the

842
00:47:24,920 --> 00:47:30,159
hard stuff, like figuring figuring all of that out in

843
00:47:30,559 --> 00:47:32,679
a framework that you're going to roll yourself is going

844
00:47:32,760 --> 00:47:36,920
to cost so much time. And that's when Martin, for instance,

845
00:47:37,079 --> 00:47:38,719
shines because it has.

846
00:47:38,639 --> 00:47:39,440
Speaker 2: All that building.

847
00:47:40,199 --> 00:47:43,199
Speaker 3: But Basin is a lot of the reason why that

848
00:47:43,480 --> 00:47:46,039
works with postgress.

849
00:47:46,159 --> 00:47:51,159
Speaker 1: Do you think agentic coding with LLLMS is going to

850
00:47:52,159 --> 00:47:57,039
help or hurt the efforts of events sourcing?

851
00:47:57,400 --> 00:48:01,119
Speaker 3: I think, But of course i'm comfort in this. I

852
00:48:01,239 --> 00:48:07,280
might be prejudiced because a lot of the patterns that

853
00:48:07,519 --> 00:48:13,400
come from using event sourcing they're relatively side effect free.

854
00:48:14,360 --> 00:48:16,679
Like your projection is going to touch the table that

855
00:48:16,760 --> 00:48:19,199
it's updating, but it's not going to touch anything else.

856
00:48:19,360 --> 00:48:21,480
It reads from the statement writes to a single table,

857
00:48:22,159 --> 00:48:24,559
and the same with your commands, like you're fetching a

858
00:48:24,599 --> 00:48:26,800
bunch of events and then you're appending to the stream.

859
00:48:26,880 --> 00:48:30,679
You're not updating records, you're not walking records. Like a

860
00:48:30,760 --> 00:48:34,320
lot of that is actually easy to performance tune down

861
00:48:34,360 --> 00:48:39,280
the line because that code is relatively side effect free.

862
00:48:40,519 --> 00:48:44,280
The patterns that are used in event sourcing would actually

863
00:48:44,519 --> 00:48:52,000
be very very adequate for generating code, because if you're

864
00:48:52,079 --> 00:48:54,440
trying to explain to an agent like, hey, this is

865
00:48:54,480 --> 00:48:57,039
what my business process looks like, these are the commands,

866
00:48:57,079 --> 00:48:59,719
and then this happens. Basically the way that we think

867
00:49:00,039 --> 00:49:04,719
out the world, right, if we figure out our drink

868
00:49:04,920 --> 00:49:07,960
order at the bar, it's a conversation, it goes back

869
00:49:08,039 --> 00:49:11,480
and forth, and it's the way our world works, is

870
00:49:11,519 --> 00:49:15,320
the way that software systems work, and especially event source systems.

871
00:49:15,760 --> 00:49:18,000
And I think that because there is less of a

872
00:49:18,079 --> 00:49:22,480
translation happening between the business problem and the actual code,

873
00:49:22,840 --> 00:49:27,000
I think this will actually lend itself very well to

874
00:49:28,639 --> 00:49:32,920
getting generated systems from from agents or whatever. Of course,

875
00:49:32,960 --> 00:49:35,719
we don't have to train them on code basis that

876
00:49:36,159 --> 00:49:39,760
deal with normalize databases, but that's not a hard problem

877
00:49:39,840 --> 00:49:42,719
to solve, right if you're training LLLMS.

878
00:49:43,159 --> 00:49:44,599
Speaker 2: I haven't done any of this testing yet, but it

879
00:49:44,639 --> 00:49:47,679
makes a lot of sense to see could we point

880
00:49:47,800 --> 00:49:52,039
an LLM at an existing SQRES implementation, say, is this

881
00:49:52,119 --> 00:49:57,920
a well implemented event source pattern application? You know, because

882
00:49:58,119 --> 00:49:59,400
the first thing I want to do is be able

883
00:49:59,400 --> 00:50:01,480
to test. Is they already doing this right before I

884
00:50:01,639 --> 00:50:04,559
even ask you to generate any code? Sure? Yeah, I've

885
00:50:04,599 --> 00:50:07,199
not tried, no, but this is an interesting idea to say,

886
00:50:07,679 --> 00:50:11,000
could these tools be really effective at this pattern based

887
00:50:11,039 --> 00:50:12,599
development approach? Yeah?

888
00:50:12,920 --> 00:50:17,199
Speaker 3: Curious est part of the reason that this is gaining

889
00:50:17,239 --> 00:50:20,639
a lot of traction in the DDD world is because

890
00:50:20,719 --> 00:50:25,960
of the lack of translation from the business concepts to

891
00:50:26,159 --> 00:50:29,440
the actual classes that you're going to see for your events.

892
00:50:29,800 --> 00:50:31,559
Speaker 2: I like the attitude, and I thought I've said this

893
00:50:31,599 --> 00:50:34,199
before on the show of Just Store the truth. Order

894
00:50:34,280 --> 00:50:36,440
comes in store the order. What you do with it

895
00:50:36,519 --> 00:50:38,760
after that is secondary the point. But the fact that

896
00:50:38,840 --> 00:50:42,840
you have a record of what happened, a complete as

897
00:50:42,920 --> 00:50:45,519
it was at the moment. I think it's really powerful.

898
00:50:45,599 --> 00:50:48,440
And the only price there is disk space, and this

899
00:50:48,559 --> 00:50:49,519
space is trivial.

900
00:50:49,639 --> 00:50:53,599
Speaker 3: It's cheap, especially if it's structured data like chasing documents.

901
00:50:54,119 --> 00:50:56,840
Speaker 1: Yeah, it's very easy, and I imagine the base on

902
00:50:57,400 --> 00:51:01,679
data takes up way less dispace. Then oh yeah, ASKI

903
00:51:02,320 --> 00:51:03,840
chasonski chasing.

904
00:51:03,920 --> 00:51:05,719
Speaker 3: But even asky chasin isn't that bad.

905
00:51:05,920 --> 00:51:09,639
Speaker 2: It's not yah, and this base is not the issue.

906
00:51:09,719 --> 00:51:11,719
I mean parsing all that after the fact, you can

907
00:51:11,840 --> 00:51:14,960
you can discuss from there, But first and foremost, it's

908
00:51:15,039 --> 00:51:16,880
just a good idea to keep a record of the truth.

909
00:51:17,360 --> 00:51:20,199
Speaker 3: You know, you can don't be mistaken like you're not

910
00:51:20,440 --> 00:51:25,320
getting auditing information like out of the box, because that's

911
00:51:25,320 --> 00:51:29,280
a common misconception about events sourcing. If you want to

912
00:51:29,400 --> 00:51:32,760
have your full audit trail of what happened for legal

913
00:51:32,840 --> 00:51:36,119
reasons or whatever, you're gonna need to enrich that data

914
00:51:36,199 --> 00:51:40,480
a little bit because who is important, Like who made

915
00:51:40,639 --> 00:51:42,920
the command that came in? What was the command that

916
00:51:43,079 --> 00:51:46,719
came in, what events resulted from that, what changes it

917
00:51:46,800 --> 00:51:50,239
a like due to the entity? Like the last part

918
00:51:50,320 --> 00:51:52,639
is what you're getting for free with your event stream,

919
00:51:52,840 --> 00:51:55,199
but you need to also lock your commands and add

920
00:51:55,280 --> 00:51:58,679
some metadata like who did this and when did they do?

921
00:51:58,880 --> 00:52:01,039
Speaker 2: Is the only thing you're getting for sure is the results,

922
00:52:01,360 --> 00:52:04,239
But to keep the detail of how you got to

923
00:52:04,360 --> 00:52:07,480
this result, that's up to you exactly where does this struggle?

924
00:52:07,719 --> 00:52:10,039
Like where do where do you get to? Where does

925
00:52:10,079 --> 00:52:10,840
this get into trouble?

926
00:52:11,000 --> 00:52:13,960
Speaker 3: Oh like GDPR becomes tricky?

927
00:52:14,559 --> 00:52:20,800
Speaker 2: Oh yeah, oh interesting, mostly protecting privably identifiable information.

928
00:52:21,079 --> 00:52:25,599
Speaker 3: Yeah, because you you in a way, you want to

929
00:52:25,719 --> 00:52:28,320
have everything that happened in your system in your in

930
00:52:28,440 --> 00:52:31,639
your streams. And it's very easy, like if Carl asks

931
00:52:31,800 --> 00:52:35,280
to have his information deleted, like we're is going to

932
00:52:35,360 --> 00:52:41,360
delete his streams from our events stream, but that might

933
00:52:41,440 --> 00:52:43,960
affect the next time that I'm running.

934
00:52:46,639 --> 00:52:49,679
Speaker 2: Check the stuff out. Yeah, well, and he's not. He's

935
00:52:49,679 --> 00:52:51,800
not asking to delete the sales record. The sales record

936
00:52:51,920 --> 00:52:56,000
is the truth. It's the identifiable information. They identifiable information.

937
00:52:56,119 --> 00:52:59,679
And then you come into situations where there's certain information

938
00:52:59,840 --> 00:53:02,480
like passwords for instance, you're not gonna want in your

939
00:53:02,519 --> 00:53:06,119
events stream, but they still need to go somewhere, right, Yeah,

940
00:53:06,599 --> 00:53:09,400
so you're you might end up masking some data in

941
00:53:09,440 --> 00:53:13,880
the event stream that you're gonna store somewhere else or

942
00:53:14,199 --> 00:53:17,199
deal with elsewhere. Right. I don't know if it's compliant,

943
00:53:17,239 --> 00:53:19,679
but my instinct there is I never modify the stream,

944
00:53:20,159 --> 00:53:22,360
but I do flag we don't have access to this

945
00:53:22,440 --> 00:53:23,239
person's information.

946
00:53:23,320 --> 00:53:26,440
Speaker 1: Anymore, so you never show it. Well, but is that

947
00:53:26,559 --> 00:53:28,480
the same as deleting it in in in.

948
00:53:30,039 --> 00:53:35,320
Speaker 3: Like I think the GDPR legislation forces you can actually

949
00:53:35,480 --> 00:53:38,320
delete ith right, you can no longer have it on file.

950
00:53:38,400 --> 00:53:40,159
Speaker 2: That's what I thought too. Yeah, so do you have

951
00:53:40,280 --> 00:53:42,679
to go back through all of your historical records that

952
00:53:42,719 --> 00:53:46,039
were burned a DVD and delete those two? That's I

953
00:53:46,159 --> 00:53:49,000
love compliance. Compliance is the best, but that's that's.

954
00:53:48,920 --> 00:53:53,119
Speaker 3: One of those problems where events sourcing gets tricky.

955
00:53:53,440 --> 00:53:57,480
Speaker 2: For instance, Yeah, this idea of keeping a record of

956
00:53:57,519 --> 00:53:58,079
the truth.

957
00:53:57,960 --> 00:54:01,239
Speaker 3: Now to be honest, like any any system here, if

958
00:54:01,280 --> 00:54:02,599
you start thinking about.

959
00:54:02,400 --> 00:54:05,320
Speaker 2: That, Yeah, and my niceing innolational database is I can

960
00:54:05,400 --> 00:54:09,039
this customer wants to be forgotten and so we erase

961
00:54:09,119 --> 00:54:11,800
their identifal inform infusiation from the record? I think I

962
00:54:12,159 --> 00:54:16,400
still keep the pointer record, like just the ID, but

963
00:54:16,519 --> 00:54:19,280
none of their information. Isn't that ID anymore? And that

964
00:54:19,559 --> 00:54:20,360
that also.

965
00:54:22,119 --> 00:54:26,960
Speaker 3: Begs the question like, okay, we still want to track

966
00:54:27,039 --> 00:54:31,239
Carl as one of the people that registered for our website,

967
00:54:31,320 --> 00:54:33,760
like how many users sign ups did we have? Right?

968
00:54:34,679 --> 00:54:37,760
And if we drop his stream like that event might

969
00:54:37,840 --> 00:54:40,320
be gone. So then you have to start thinking about Okay,

970
00:54:40,440 --> 00:54:45,000
if we want to model that particular bit of information

971
00:54:45,159 --> 00:54:47,920
like new users signed up, we're going to have to

972
00:54:48,000 --> 00:54:51,440
have a user signed up event in another aggregate that

973
00:54:51,559 --> 00:54:55,880
does not get deleted when Carl's stream is removed from

974
00:54:55,920 --> 00:54:59,039
the system, so that that information is still still accurate.

975
00:54:59,199 --> 00:55:05,480
Like those things becomes more intentional.

976
00:55:06,639 --> 00:55:09,280
Speaker 1: Do you leave the name and erase everything else or

977
00:55:09,360 --> 00:55:12,159
replace it with not available or scrubbed or something like

978
00:55:12,239 --> 00:55:13,639
redacted or something like that.

979
00:55:14,079 --> 00:55:17,400
Speaker 3: There's there's different different approaches that you can take. Yeah,

980
00:55:18,480 --> 00:55:22,079
but very very most Margin for instance, allows you to

981
00:55:22,280 --> 00:55:27,719
archive certain streams, which means that like this aggregate is

982
00:55:27,760 --> 00:55:29,239
never going to get fetched back again.

983
00:55:29,400 --> 00:55:29,880
Speaker 2: And then.

984
00:55:31,719 --> 00:55:34,840
Speaker 3: In theory, you could just delete that from the database.

985
00:55:35,280 --> 00:55:39,000
You could go through you could execute a simple command

986
00:55:39,039 --> 00:55:43,000
saying like every every event where we have the archived

987
00:55:43,079 --> 00:55:46,239
flag set to TROW, we can delete that. But then

988
00:55:46,280 --> 00:55:49,159
you have to really worry about like, okay, which projections

989
00:55:49,599 --> 00:55:51,960
might that affect and is that a bad thing? Is

990
00:55:52,000 --> 00:55:52,679
that a problem?

991
00:55:52,760 --> 00:55:53,039
Speaker 2: Okay?

992
00:55:53,159 --> 00:55:57,039
Speaker 3: If this, and that's also a reason why you might

993
00:55:57,199 --> 00:56:00,320
want to rebuild stuff, because I might delete the data

994
00:56:00,400 --> 00:56:03,920
from the stream, I might delete defense, but the data

995
00:56:04,000 --> 00:56:08,960
might still be in the projected in the projection tables.

996
00:56:09,719 --> 00:56:15,360
So that's one of the reasons to periodically rerun or update,

997
00:56:15,719 --> 00:56:18,119
like rebuild certain protections.

998
00:56:18,440 --> 00:56:20,880
Speaker 2: And you got to get I'm so low to the

999
00:56:21,000 --> 00:56:24,039
leade data just because you know what you are, you

1000
00:56:24,119 --> 00:56:25,920
sure you're deleting the right things, Like I can also

1001
00:56:25,960 --> 00:56:28,480
get in trouble with the government for not reporting sales

1002
00:56:28,519 --> 00:56:31,599
because I had to forget this person and forgot their sales.

1003
00:56:32,079 --> 00:56:34,280
Speaker 1: Yeah, well that's true. Got to keep it around at

1004
00:56:34,360 --> 00:56:35,760
least until you pay the sales.

1005
00:56:35,559 --> 00:56:38,199
Speaker 2: Tax or whatever that. Yeah, and probably have to keep

1006
00:56:38,199 --> 00:56:40,159
it around forever you can. You know, you get audited,

1007
00:56:40,480 --> 00:56:42,679
you still have to make sure your sales are correct. Yeah,

1008
00:56:42,679 --> 00:56:44,920
there's a in the United States, there's like a ten

1009
00:56:45,000 --> 00:56:47,840
year window or something after which you can delete anything

1010
00:56:47,880 --> 00:56:50,000
you want. Yeah, but even then you I mean, it's

1011
00:56:50,039 --> 00:56:51,960
smart to keep track of all of your sales, who

1012
00:56:52,039 --> 00:56:54,960
you sold it to. That's identifiable information. You can delete that,

1013
00:56:55,239 --> 00:56:58,239
yeah yeah, yeah, yeah. I just suddenly have this vision

1014
00:56:58,280 --> 00:57:02,159
of you have these streams marked GDPR redacted user yeah

1015
00:57:02,320 --> 00:57:05,320
number you know eleven, that kind of thing.

1016
00:57:06,280 --> 00:57:11,480
Speaker 3: If certain events, for instance, contain identifiable information, you can

1017
00:57:11,719 --> 00:57:13,719
mask that. You can say, like this field and that

1018
00:57:13,960 --> 00:57:17,559
type of event. I don't want it to be safe

1019
00:57:17,599 --> 00:57:18,119
to the stream.

1020
00:57:18,440 --> 00:57:21,679
Speaker 1: And then you just but if the federalies say you

1021
00:57:21,800 --> 00:57:23,360
have to delete it, you have to delete it.

1022
00:57:23,519 --> 00:57:26,199
Speaker 2: Yeah, answers the question of what are you deleting, right

1023
00:57:26,559 --> 00:57:29,280
because at the same time I have another federale saying

1024
00:57:29,599 --> 00:57:33,360
you can't delete sales records. Yea, I will send you

1025
00:57:33,440 --> 00:57:34,559
to prison for hiding income.

1026
00:57:34,880 --> 00:57:39,679
Speaker 3: Another thing that becomes tricky over time is versioning of events.

1027
00:57:40,480 --> 00:57:43,559
Events may evolve over time and become.

1028
00:57:43,440 --> 00:57:46,719
Speaker 2: Sure new version of the sotom more elaborate or more

1029
00:57:46,840 --> 00:57:48,719
complex or simpler.

1030
00:57:48,880 --> 00:57:52,119
Speaker 3: A certain command might certainly spawn two events instead of one.

1031
00:57:52,760 --> 00:57:57,719
Suddenly you have as long as your objects are backwards

1032
00:57:57,760 --> 00:58:01,239
compatible to whatever is saved in or data store, like,

1033
00:58:01,360 --> 00:58:03,880
that's not a problem. But at some time you're going

1034
00:58:03,960 --> 00:58:04,400
to break that.

1035
00:58:04,719 --> 00:58:09,280
Speaker 2: Yeah, you a replayable state somehow. And the easiest thing

1036
00:58:09,440 --> 00:58:10,079
is is to.

1037
00:58:11,679 --> 00:58:14,039
Speaker 3: To just have the two versions in your code. Just

1038
00:58:14,159 --> 00:58:17,800
have two versions of that event in two different namespaces

1039
00:58:17,880 --> 00:58:19,920
or with two different class names or whatever. And that

1040
00:58:20,039 --> 00:58:20,679
works fine.

1041
00:58:20,719 --> 00:58:23,159
Speaker 2: But that because how sweet do you think we're only

1042
00:58:23,199 --> 00:58:23,920
going to have two?

1043
00:58:25,840 --> 00:58:28,639
Speaker 3: That becomes a mess over time, And then you start,

1044
00:58:29,199 --> 00:58:34,719
Then you start practicing things like upcasting or but that's

1045
00:58:34,960 --> 00:58:39,519
that's something that I tried to steer away from as

1046
00:58:39,639 --> 00:58:43,199
long as I can, and ideally never do, is start

1047
00:58:43,400 --> 00:58:47,440
updating the table and upcasting the events and resaving them

1048
00:58:47,559 --> 00:58:53,800
too ideally new streams. But that's a tricky mechanism as well,

1049
00:58:53,880 --> 00:58:56,119
because your new stream will have new eyelins to it.

1050
00:58:56,159 --> 00:58:59,280
It's now incorrect, and it escalates, it escalates.

1051
00:58:59,320 --> 00:59:02,159
Speaker 1: I think when I hear you're saying, is higher harness

1052
00:59:02,320 --> 00:59:03,880
if you want to tackle these problems?

1053
00:59:04,119 --> 00:59:07,039
Speaker 3: Yeah, well yeah, And there's there's a bunch of other

1054
00:59:07,159 --> 00:59:09,480
people out there that do great work in this space

1055
00:59:09,559 --> 00:59:12,719
as well. Like if you think about Oscar do for instance,

1056
00:59:13,400 --> 00:59:17,239
you've met Oscar right. Oscar does some great stuff with

1057
00:59:17,400 --> 00:59:20,559
events sourcing, and the whole d d D community seems

1058
00:59:20,639 --> 00:59:25,519
to have adopted this as their pattern of choice. So

1059
00:59:25,599 --> 00:59:29,519
there's many many people out there. But like think before

1060
00:59:29,639 --> 00:59:34,400
you actually do this. And this works very well if

1061
00:59:34,480 --> 00:59:40,880
you have complex domains that need to be modeled in

1062
00:59:41,079 --> 00:59:45,519
code where you have high concurrency, for instance, because it's

1063
00:59:45,599 --> 00:59:49,480
very good at dealing with that very explicit business logic.

1064
00:59:49,599 --> 00:59:51,679
You don't want to have too many side effects. That's

1065
00:59:51,760 --> 00:59:56,639
a very good reason to choose for this, But in general,

1066
00:59:56,800 --> 01:00:01,119
as soon as you become proficient at this, you start

1067
01:00:01,199 --> 01:00:04,159
using it for a lot more things because it's.

1068
01:00:04,159 --> 01:00:06,440
Speaker 2: Just so easy. Yeah, it's definitely. It sounds like a

1069
01:00:06,519 --> 01:00:08,760
pattern that once you get the groove, you see places

1070
01:00:08,800 --> 01:00:10,840
to use it. But it's not everything.

1071
01:00:11,079 --> 01:00:14,280
Speaker 3: It's just you have to flip the switch in your

1072
01:00:14,440 --> 01:00:18,880
brain and for me, that live cycle of command comes in.

1073
01:00:19,119 --> 01:00:24,000
We replay events, then we execute our business logic and

1074
01:00:24,159 --> 01:00:26,760
that spawns new events which we now append to the

1075
01:00:26,800 --> 01:00:29,840
stream again. As soon as that clicks in your head

1076
01:00:30,800 --> 01:00:34,840
like it's no, it's not harder or easier than working

1077
01:00:35,000 --> 01:00:39,559
with normal entities that you're pulling through entity framework from

1078
01:00:39,639 --> 01:00:41,880
your r M and then calling safe changes. I mean,

1079
01:00:41,960 --> 01:00:46,400
it's it's it's a trivial, a trivial amount of thinking

1080
01:00:46,840 --> 01:00:48,800
to fit that in.

1081
01:00:49,079 --> 01:00:51,320
Speaker 2: Well, honess what's next for you? What are you doing?

1082
01:00:52,320 --> 01:00:53,159
What's in your inbox?

1083
01:00:53,320 --> 01:00:57,880
Speaker 3: I'm leaving on holiday tomorrow or where you're thinking about

1084
01:00:59,159 --> 01:01:01,719
what's next for me professionally? Either you know where you're

1085
01:01:01,719 --> 01:01:05,719
going so European, I'm going I'm going to the to

1086
01:01:05,840 --> 01:01:09,000
the Dutch coast with my family. We're going to go

1087
01:01:09,079 --> 01:01:12,280
to a little house that's actually on the beach, much

1088
01:01:12,519 --> 01:01:15,000
like the way that Richard lives, but not as fans.

1089
01:01:15,079 --> 01:01:20,119
Speaker 2: Wow, no fancy, my place has been Okay, that's pretty we.

1090
01:01:21,880 --> 01:01:24,400
Speaker 3: We will have neighbors for instance, that we can see.

1091
01:01:30,760 --> 01:01:31,239
Speaker 2: The family.

1092
01:01:31,440 --> 01:01:33,599
Speaker 3: The family is going to to the ghost and and

1093
01:01:33,679 --> 01:01:36,519
I'm gonna recuperate for a little bit because I've had

1094
01:01:36,559 --> 01:01:40,000
a rough year, like renovating a house and and becoming

1095
01:01:40,039 --> 01:01:43,960
an independent contractor for half of my time and making

1096
01:01:44,039 --> 01:01:47,880
courses and all that sort of stuff. And what's next

1097
01:01:48,440 --> 01:01:53,199
professionally what I'm hoping to do in the fall, because

1098
01:01:53,199 --> 01:01:56,280
I've just released two courses on events sourcing on the

1099
01:01:56,320 --> 01:01:59,840
Home Train and the second one. There's like two more

1100
01:02:00,079 --> 01:02:02,840
chapters that I really want to make that aren't there yet,

1101
01:02:04,719 --> 01:02:06,760
So that might be a thing that I'm that I'm

1102
01:02:06,800 --> 01:02:10,400
going to do in the fall. Great. Yeah, while we're

1103
01:02:10,440 --> 01:02:13,880
looking and it's looking like conference season is going to

1104
01:02:13,960 --> 01:02:19,360
be busy from November to beginning December, so I'll probably

1105
01:02:19,480 --> 01:02:22,159
run into you guys a couple of times somewhere somewhere.

1106
01:02:22,320 --> 01:02:25,920
Speaker 2: All right, Well, that man, this is great stuff. Thanks Hanas. Yeah,

1107
01:02:26,119 --> 01:02:26,800
great talking to you.

1108
01:02:27,119 --> 01:02:29,760
Speaker 3: I was happy to be on the show and thanks

1109
01:02:29,800 --> 01:02:33,079
for letting me rand a little bit about this thing

1110
01:02:33,119 --> 01:02:34,320
that I'm really passionate about.

1111
01:02:34,400 --> 01:02:39,239
Speaker 2: Absolutely crazy explanation. Thanks so much, very clear, all right,

1112
01:02:39,440 --> 01:02:42,719
and we'll talk to you next time on dot net rocks.

1113
01:03:03,880 --> 01:03:06,440
Speaker 4: Dot net Rocks is brought to you by Franklin's Net

1114
01:03:06,719 --> 01:03:10,639
and produced by Pop Studios, a full service audio, video

1115
01:03:10,760 --> 01:03:14,760
and post production facility located physically in New London, Connecticut,

1116
01:03:15,079 --> 01:03:19,280
and of course in the cloud online at pwop dot com.

1117
01:03:20,079 --> 01:03:22,119
Visit our website at d O T N E t

1118
01:03:22,440 --> 01:03:26,440
R O c k S dot com for RSS feeds, downloads,

1119
01:03:26,599 --> 01:03:30,280
mobile apps, comments, and access to the full archives going

1120
01:03:30,320 --> 01:03:33,719
back to show number one, recorded in September two thousand

1121
01:03:33,719 --> 01:03:33,960
and two.

1122
01:03:34,639 --> 01:03:35,239
Speaker 2: And make sure you.

1123
01:03:35,320 --> 01:03:38,360
Speaker 4: Check out our sponsors. They keep us in business. Now

1124
01:03:38,440 --> 01:03:40,679
go write some code, See you next time.

1125
01:03:41,599 --> 01:03:43,440
Speaker 3: You got jam Vans

1126
01:03:45,480 --> 01:03:45,519
Speaker 2: And