WEBVTT

1
00:00:01.080 --> 00:00:03.799
<v Speaker 1>How'd you like to listen to dot NetRocks with no ads?

2
00:00:04.440 --> 00:00:04.799
<v Speaker 2>Easy?

3
00:00:05.360 --> 00:00:08.560
<v Speaker 1>Become a patron for just five dollars a month. You

4
00:00:08.599 --> 00:00:11.320
<v Speaker 1>get access to a private RSS feed where all the

5
00:00:11.359 --> 00:00:14.599
<v Speaker 1>shows have no ads. Twenty dollars a month, we'll get

6
00:00:14.599 --> 00:00:18.440
<v Speaker 1>you that and a special dot NetRocks patron mug. Sign

7
00:00:18.519 --> 00:00:34.560
<v Speaker 1>up now at Patreon dot dot NetRocks dot com. Hey

8
00:00:34.600 --> 00:00:37.240
<v Speaker 1>guess what, it's dot net rocks. I'm Carl Franklin at

9
00:00:37.280 --> 00:00:41.039
<v Speaker 1>amiraterid Cabell. We're here again for the nineteen hundredth and

10
00:00:41.079 --> 00:00:42.399
<v Speaker 1>sixty first time.

11
00:00:42.600 --> 00:00:43.039
<v Speaker 2>Well you.

12
00:00:44.479 --> 00:00:47.920
<v Speaker 1>Okay, you're here for the eighteen hundred and sixtieth time.

13
00:00:48.159 --> 00:00:50.000
<v Speaker 2>I think something like that. Second.

14
00:00:50.119 --> 00:00:55.039
<v Speaker 1>I'm the new guy, remember new guy new the new guy. Yeah,

15
00:00:55.079 --> 00:00:57.880
<v Speaker 1>we are the OG podcast certainly when it comes to development,

16
00:00:58.000 --> 00:01:01.359
<v Speaker 1>and one of the first five that's still existence since

17
00:01:01.439 --> 00:01:05.120
<v Speaker 1>podcast hit the ground running. We've been going since August

18
00:01:05.439 --> 00:01:08.959
<v Speaker 1>two thousand and two, A long, long, long, long time.

19
00:01:09.159 --> 00:01:11.959
<v Speaker 2>It's been a while. Yeah, how are you, Richard? I'm good.

20
00:01:12.000 --> 00:01:15.200
<v Speaker 2>It's summertime, and summertime it's good. Sometimes it's beautiful on

21
00:01:15.239 --> 00:01:15.560
<v Speaker 2>the coast.

22
00:01:15.879 --> 00:01:18.640
<v Speaker 1>It's a little hot where I am, but it's not bad.

23
00:01:19.040 --> 00:01:20.959
<v Speaker 2>It's not bad. It could be worse. Well, and she

24
00:01:21.040 --> 00:01:24.319
<v Speaker 2>who must be obeyed is turning sixty, so I've well,

25
00:01:24.319 --> 00:01:25.920
<v Speaker 2>at this point we'll have thrown that party.

26
00:01:26.400 --> 00:01:30.680
<v Speaker 1>So wow, it's always congratulations Stace. All right, let's roll

27
00:01:30.719 --> 00:01:33.680
<v Speaker 1>the crazy music because I've got something for Hannas for

28
00:01:33.799 --> 00:01:35.280
<v Speaker 1>better no framework awesome?

29
00:01:43.079 --> 00:01:43.959
<v Speaker 2>All right, man, what do you got?

30
00:01:44.079 --> 00:01:46.280
<v Speaker 1>Since this is episode nineteen sixty one, you can go

31
00:01:46.319 --> 00:01:50.120
<v Speaker 1>to nineteen sixty one dot dot me and that brings

32
00:01:50.159 --> 00:01:54.560
<v Speaker 1>you to this article from Menga, which is just somebody's

33
00:01:54.560 --> 00:01:57.719
<v Speaker 1>blog I think. I don't even know the name of

34
00:01:57.719 --> 00:02:01.719
<v Speaker 1>the person, doesn't even say all right, but anyway, it's

35
00:02:01.799 --> 00:02:06.400
<v Speaker 1>called computerized guitars and whether they're worth buying or not.

36
00:02:07.400 --> 00:02:10.960
<v Speaker 1>I know, Hanness plays guitar and makes guitars and yeah.

37
00:02:10.919 --> 00:02:11.840
<v Speaker 2>Builds guitars.

38
00:02:11.919 --> 00:02:16.599
<v Speaker 1>Yes, he's a guitar guy, right, Yeah, So this article

39
00:02:16.800 --> 00:02:23.000
<v Speaker 1>basically says nobody likes these electronic you know, computerized guitars. Really,

40
00:02:23.000 --> 00:02:25.439
<v Speaker 1>nobody likes them. Nobody wants one.

41
00:02:25.560 --> 00:02:29.240
<v Speaker 3>There's some weird experiments out there, like there are Gibson

42
00:02:29.280 --> 00:02:34.120
<v Speaker 3>experiment with de robotic tuners and volunteery that that's great,

43
00:02:34.240 --> 00:02:36.759
<v Speaker 3>and nobody seems to want that on their guitar.

44
00:02:36.680 --> 00:02:37.759
<v Speaker 2>That's just it. You know.

45
00:02:38.120 --> 00:02:41.520
<v Speaker 1>The sales say that they're cool, but nobody wants them,

46
00:02:41.560 --> 00:02:44.360
<v Speaker 1>like the Gibson Firebird X, which is I think the one,

47
00:02:44.479 --> 00:02:46.680
<v Speaker 1>or Firebird ten, which is I think what you're talking about,

48
00:02:47.439 --> 00:02:50.800
<v Speaker 1>and the Les Paul Robot guitar was another one. But

49
00:02:51.520 --> 00:02:55.680
<v Speaker 1>this is without question the most computerized electric guitar in

50
00:02:55.680 --> 00:02:59.639
<v Speaker 1>the market right now. It has everything on it. The

51
00:02:59.680 --> 00:03:03.199
<v Speaker 1>only it doesn't have is sales. Nice nobody bought it,

52
00:03:03.319 --> 00:03:08.039
<v Speaker 1>and Gibson actually ended up crushing, like with a bulldozer,

53
00:03:09.000 --> 00:03:11.719
<v Speaker 1>about a hundred of these things because they were a

54
00:03:11.759 --> 00:03:15.840
<v Speaker 1>liability to have on the books, because they got had

55
00:03:15.840 --> 00:03:18.159
<v Speaker 1>to get rid of their inventory, and because nobody was

56
00:03:18.199 --> 00:03:18.719
<v Speaker 1>buying them.

57
00:03:18.960 --> 00:03:24.879
<v Speaker 3>Weirdly, Yeah, like every every guitar manufacturer that does strangely

58
00:03:24.960 --> 00:03:29.360
<v Speaker 3>innovative stuff has been has been having trouble selling them.

59
00:03:29.439 --> 00:03:31.840
<v Speaker 3>Like my favorite guitar that I own is a park

60
00:03:31.919 --> 00:03:35.520
<v Speaker 3>Or Fly, which was way ahead of its time, and

61
00:03:35.599 --> 00:03:38.759
<v Speaker 3>they struggled to sell them. Yeah, although they were selling

62
00:03:38.800 --> 00:03:41.520
<v Speaker 3>guitars that were actually work twice what they were selling

63
00:03:41.560 --> 00:03:45.360
<v Speaker 3>them for, but nobody bought them because they were so unconventional.

64
00:03:45.479 --> 00:03:49.199
<v Speaker 1>Yeah, and so let me just point out the other

65
00:03:49.199 --> 00:03:53.080
<v Speaker 1>ones here the Fender Veg stratocaster, and I actually have

66
00:03:53.240 --> 00:03:55.280
<v Speaker 1>one of these, but it was before that it was

67
00:03:55.319 --> 00:03:58.319
<v Speaker 1>the Fender Veg. It's a Fender strat, but it also

68
00:03:58.439 --> 00:04:02.120
<v Speaker 1>has the role In logo on it because you can

69
00:04:02.199 --> 00:04:07.280
<v Speaker 1>connect it to the rollin VG system and it's got

70
00:04:07.280 --> 00:04:09.879
<v Speaker 1>the right pick up in there and all. But as

71
00:04:09.919 --> 00:04:14.080
<v Speaker 1>a strat, it's just kind of bleuh right, I have

72
00:04:14.400 --> 00:04:17.399
<v Speaker 1>a strat plus that I love. I mean, it's hard

73
00:04:17.439 --> 00:04:19.160
<v Speaker 1>to keep in tune and all that stuff, like a

74
00:04:19.279 --> 00:04:22.279
<v Speaker 1>regular strat is, but at least it's a good sounding strat.

75
00:04:23.120 --> 00:04:26.720
<v Speaker 2>The isn't the question here why people play guitar, because

76
00:04:26.839 --> 00:04:30.480
<v Speaker 2>most people who play guitar aren't making money playing guitar. No,

77
00:04:30.680 --> 00:04:32.079
<v Speaker 2>that's true, sadly no.

78
00:04:32.759 --> 00:04:36.920
<v Speaker 1>They also mentioned the epiphone Les Paul Ultra, which has

79
00:04:36.959 --> 00:04:39.319
<v Speaker 1>a USB port where you can connect the guitar to

80
00:04:39.800 --> 00:04:43.360
<v Speaker 1>you know, your computer. The problem with that is that

81
00:04:45.920 --> 00:04:48.879
<v Speaker 1>he says here too, machines and computers just don't mix

82
00:04:49.279 --> 00:04:52.319
<v Speaker 1>when it comes to guitars. An electric guitar is a

83
00:04:52.360 --> 00:04:54.959
<v Speaker 1>machine that by nature is a very physical instrument. This

84
00:04:55.040 --> 00:04:57.920
<v Speaker 1>isn't like a synthesizer where it just sits there and

85
00:04:57.959 --> 00:05:00.360
<v Speaker 1>you play it with a guitar, you sit down way that,

86
00:05:00.399 --> 00:05:02.240
<v Speaker 1>you stand up with that you move around playing and

87
00:05:02.240 --> 00:05:07.839
<v Speaker 1>so on. But most players consider these computerized guitars not

88
00:05:07.879 --> 00:05:11.639
<v Speaker 1>real instruments because, let's face it, the sound of playing

89
00:05:11.680 --> 00:05:17.199
<v Speaker 1>a synth through a guitar is just no, it's just bad.

90
00:05:19.600 --> 00:05:22.480
<v Speaker 1>So they're out there. I think if I was going

91
00:05:22.560 --> 00:05:24.839
<v Speaker 1>to get one, I'd just get an automatic tuning one

92
00:05:24.839 --> 00:05:25.519
<v Speaker 1>and leave it at that.

93
00:05:25.759 --> 00:05:30.639
<v Speaker 3>Actually that system works, it's not that yeah, yeah, it's

94
00:05:30.759 --> 00:05:33.680
<v Speaker 3>just good. Well, in this blog post is thirteen years old.

95
00:05:33.759 --> 00:05:36.240
<v Speaker 3>You think the technology has probably moved on a little

96
00:05:36.240 --> 00:05:36.839
<v Speaker 3>from there.

97
00:05:36.959 --> 00:05:39.199
<v Speaker 1>Yeah, a little bit, but I mean those are still

98
00:05:39.319 --> 00:05:41.680
<v Speaker 1>not that much though. Those are still the models that

99
00:05:41.959 --> 00:05:44.199
<v Speaker 1>you know that people like, except for the Fiber ten,

100
00:05:44.279 --> 00:05:46.519
<v Speaker 1>which is not available anywhere.

101
00:05:46.639 --> 00:05:50.199
<v Speaker 3>Actually, the musician that has done the weirdest stuff to

102
00:05:50.839 --> 00:05:53.079
<v Speaker 3>some of their guitars that a lot of people might

103
00:05:53.120 --> 00:05:57.079
<v Speaker 3>know about is Matt Bellamy from muse Be built in

104
00:05:57.199 --> 00:06:01.720
<v Speaker 3>like x Y controllers that control synthesizers that were like

105
00:06:01.839 --> 00:06:06.000
<v Speaker 3>controlled from his guitar and built in effects into the

106
00:06:06.000 --> 00:06:09.800
<v Speaker 3>body of the guitar. Like that had more electronics in

107
00:06:09.879 --> 00:06:13.199
<v Speaker 3>it than a lot of other instruments out there.

108
00:06:13.399 --> 00:06:13.639
<v Speaker 2>Right.

109
00:06:13.720 --> 00:06:16.600
<v Speaker 1>Well, and then you got guys like Brian May who

110
00:06:16.720 --> 00:06:20.279
<v Speaker 1>just made a very unique sounding guitar working with phase

111
00:06:20.920 --> 00:06:25.000
<v Speaker 1>cancelation and phasing and all that stuff. But you know

112
00:06:25.040 --> 00:06:28.839
<v Speaker 1>he's just just built by himself, Yeah, and his father, Yeah, out.

113
00:06:28.680 --> 00:06:32.439
<v Speaker 3>Of very unconventional woods in the guitar world. He used

114
00:06:32.480 --> 00:06:34.680
<v Speaker 3>things like oh, which nobody he uses.

115
00:06:35.040 --> 00:06:37.959
<v Speaker 1>Yeah. So anyway, that's what I got today. And I

116
00:06:38.000 --> 00:06:40.439
<v Speaker 1>thought we would have a nice conversation about guitars, and

117
00:06:40.480 --> 00:06:40.959
<v Speaker 1>we did so.

118
00:06:41.240 --> 00:06:43.920
<v Speaker 2>Yeah. Richard, who's talking to us today, grabbed a comment

119
00:06:44.000 --> 00:06:46.199
<v Speaker 2>off a show nineteen thirty nine, which is the one

120
00:06:46.240 --> 00:06:48.920
<v Speaker 2>we did with Jeremy Miller talking about vertical slice architecture,

121
00:06:48.920 --> 00:06:51.319
<v Speaker 2>and I know we got into events, sourcing and things

122
00:06:51.319 --> 00:06:53.600
<v Speaker 2>with him at one point or another. Two. This comment

123
00:06:53.639 --> 00:06:57.360
<v Speaker 2>comes from cash bon Fields, who said, you mentioned the

124
00:06:57.360 --> 00:06:59.639
<v Speaker 2>buzz factor, which is how many people could be hit

125
00:06:59.680 --> 00:07:02.199
<v Speaker 2>by a by while the project still survives. I have

126
00:07:02.279 --> 00:07:05.079
<v Speaker 2>been recently considering the opposite, how many people should be

127
00:07:05.160 --> 00:07:07.079
<v Speaker 2>hit by a bus for a project to be effective.

128
00:07:08.560 --> 00:07:11.079
<v Speaker 2>The bus should most often be used for selecting managers,

129
00:07:11.079 --> 00:07:15.199
<v Speaker 2>though I think there's a little anger in their cash.

130
00:07:15.240 --> 00:07:19.759
<v Speaker 2>You want to talk to someone, don't don't hurt anybody. No,

131
00:07:20.079 --> 00:07:23.439
<v Speaker 2>I get you. You know, there's definitely that effect of this.

132
00:07:23.800 --> 00:07:26.120
<v Speaker 2>You know, how many cooks before you spoil the soup

133
00:07:26.279 --> 00:07:29.879
<v Speaker 2>kind of thing, right, And we were six months behind

134
00:07:29.879 --> 00:07:31.480
<v Speaker 2>on the project, so they had a developer. Now we're

135
00:07:31.560 --> 00:07:38.079
<v Speaker 2>nine months behind on the project. People don't understand how

136
00:07:38.079 --> 00:07:40.240
<v Speaker 2>to fix things. Hey, I got you the I got

137
00:07:40.240 --> 00:07:42.759
<v Speaker 2>your book Mythical Man month, but actually got you two

138
00:07:42.759 --> 00:07:47.720
<v Speaker 2>of them so you can read it twice as fast. Boom, yeah, Cash,

139
00:07:47.759 --> 00:07:49.199
<v Speaker 2>Thank you so much for your comment, and a copy

140
00:07:49.199 --> 00:07:50.560
<v Speaker 2>of music Coba is on its way to you. And

141
00:07:50.600 --> 00:07:52.199
<v Speaker 2>if you'd like a copy of music Cobe. I read

142
00:07:52.240 --> 00:07:54.120
<v Speaker 2>a comment on the website at dot and rocks dot

143
00:07:54.160 --> 00:07:56.600
<v Speaker 2>com on the facebooks. We publish every show there, and

144
00:07:56.639 --> 00:07:58.199
<v Speaker 2>if you comment there and I read it on the show,

145
00:07:58.240 --> 00:08:00.360
<v Speaker 2>we'll send you a copy of music. Go buy Cobey

146
00:08:00.439 --> 00:08:01.319
<v Speaker 2>is still going strong.

147
00:08:01.560 --> 00:08:05.959
<v Speaker 1>Twenty two chapters if you call them or episodes or tracks,

148
00:08:06.040 --> 00:08:06.639
<v Speaker 1>I guess I.

149
00:08:06.639 --> 00:08:07.600
<v Speaker 2>Kind of like chapters.

150
00:08:07.720 --> 00:08:10.879
<v Speaker 1>Twenty two tracks, yeah, whatever you want to call them.

151
00:08:10.879 --> 00:08:13.680
<v Speaker 1>There's twenty two musical tracks and they're all twenty five

152
00:08:13.680 --> 00:08:17.639
<v Speaker 1>minutes long, perfect for your Pomadoro technique. Music took code

153
00:08:17.639 --> 00:08:20.240
<v Speaker 1>by dot net all right, before we bring on Haness

154
00:08:20.360 --> 00:08:25.759
<v Speaker 1>what happened in nineteen sixty one besides John F. Kennedy's inauguration,

155
00:08:26.519 --> 00:08:29.120
<v Speaker 1>after which he immediately invaded.

156
00:08:28.720 --> 00:08:33.679
<v Speaker 2>Cuba by pigs thigs. Yeah, I don't know, just parallel,

157
00:08:33.759 --> 00:08:36.000
<v Speaker 2>maybe kind of a hairy year, no two ways about it,

158
00:08:36.039 --> 00:08:36.720
<v Speaker 2>and without a dough.

159
00:08:37.200 --> 00:08:40.000
<v Speaker 1>Yeah, the establishment of the Peace Corps and Juriga Garin

160
00:08:40.039 --> 00:08:45.639
<v Speaker 1>became their first official human to travel into space. Additionally,

161
00:08:45.720 --> 00:08:49.120
<v Speaker 1>the and directly into orbit too, you know, yeah, she

162
00:08:49.440 --> 00:08:51.679
<v Speaker 1>orbited as opposed to you know, the US first effort

163
00:08:51.720 --> 00:08:54.039
<v Speaker 1>with Alan Shepard in the sub ardable flight. Yeah, yeah,

164
00:08:54.240 --> 00:08:58.240
<v Speaker 1>so I know, there's all the Beatles came in, you

165
00:08:58.279 --> 00:09:00.600
<v Speaker 1>know around there, I said, the Peace Corps, some nuclear

166
00:09:00.639 --> 00:09:05.159
<v Speaker 1>testing was going on in the Soviet Union, and the

167
00:09:05.200 --> 00:09:08.399
<v Speaker 1>Academy Awards thirty third Academy Awards took place, with the

168
00:09:08.440 --> 00:09:11.639
<v Speaker 1>Apartment winning Best Picture. You know, just some random trivia.

169
00:09:11.679 --> 00:09:15.080
<v Speaker 1>But you've got the reallest Richard, what really happened in

170
00:09:15.159 --> 00:09:16.000
<v Speaker 1>nineteen sixty one?

171
00:09:16.399 --> 00:09:18.720
<v Speaker 2>I mean I always go off to the invention side,

172
00:09:19.200 --> 00:09:21.639
<v Speaker 2>just because you know, so many cool things are made.

173
00:09:21.720 --> 00:09:25.120
<v Speaker 2>Sixty one is when the first industrial robot is deployed

174
00:09:25.120 --> 00:09:28.840
<v Speaker 2>into a factory. It's called Unimate. It had been developed

175
00:09:28.840 --> 00:09:32.399
<v Speaker 2>in the fifties by George Deval and General Motors puts

176
00:09:32.399 --> 00:09:38.159
<v Speaker 2>it into a automotive factory to remove metal parts from

177
00:09:38.200 --> 00:09:41.039
<v Speaker 2>a die caster. So a die caster is basically a

178
00:09:41.080 --> 00:09:44.919
<v Speaker 2>big hydraulic ram. You put sheets of metal into it

179
00:09:44.960 --> 00:09:47.039
<v Speaker 2>and it slams them into the shape of like a

180
00:09:47.080 --> 00:09:51.320
<v Speaker 2>door panel. But that force that molds that that quickly

181
00:09:51.480 --> 00:09:54.799
<v Speaker 2>makes the metal really HoTT. So not when a person

182
00:09:55.120 --> 00:09:57.080
<v Speaker 2>has handled at any clubs and things, is very easy

183
00:09:57.120 --> 00:09:59.240
<v Speaker 2>get burned like it's dangerous work. And so having the

184
00:09:59.320 --> 00:10:02.600
<v Speaker 2>robot deal with that we made a lot of sense. Made sense. Yeah,

185
00:10:02.639 --> 00:10:05.600
<v Speaker 2>And over the next decade or so, automation would come

186
00:10:06.080 --> 00:10:08.480
<v Speaker 2>throughout the factory process. So it begins in sixty one

187
00:10:08.480 --> 00:10:11.480
<v Speaker 2>with the Unimate. A little corollary to that, as they

188
00:10:11.480 --> 00:10:15.600
<v Speaker 2>were celebrating the Unimate success, it got an appearance on

189
00:10:15.799 --> 00:10:18.320
<v Speaker 2>Johnny Carson and poured a cup of coffee.

190
00:10:18.600 --> 00:10:21.759
<v Speaker 1>I think I do remember that. Yeah, yeah, it was

191
00:10:21.799 --> 00:10:24.519
<v Speaker 1>ninety sixty one. You were not born yet, no, but

192
00:10:24.559 --> 00:10:27.440
<v Speaker 1>I saw the rerun that was a famous famous clips.

193
00:10:27.200 --> 00:10:30.240
<v Speaker 2>Could be famous episode. Nineteen sixty one is also the

194
00:10:30.279 --> 00:10:36.759
<v Speaker 2>first integrated circuit in production. Now I step into this

195
00:10:37.000 --> 00:10:41.720
<v Speaker 2>very carefully because it is a hotly contested topic. In fact,

196
00:10:41.879 --> 00:10:45.200
<v Speaker 2>it's got a Wikipedia entry just on the invention of

197
00:10:45.200 --> 00:10:48.240
<v Speaker 2>the integrated circuit, because there's lots of arguments here. I mean,

198
00:10:48.320 --> 00:10:51.080
<v Speaker 2>for I mean meaning who did it first? Yeah? And

199
00:10:51.120 --> 00:10:53.960
<v Speaker 2>what represents an integrated circuit? Mean, we'd been messed around

200
00:10:53.960 --> 00:10:55.840
<v Speaker 2>with semi conductors for a while, We've made a bunch

201
00:10:55.840 --> 00:10:59.240
<v Speaker 2>of different kinds of transistors. You've got Back at fifty

202
00:10:59.240 --> 00:11:04.320
<v Speaker 2>twosh radio engineer Jeffrey Dummer was making semiconductor circuits. There's

203
00:11:04.360 --> 00:11:10.360
<v Speaker 2>also Harwick Johnson, Sydney Darlington, Yasatarui. But it really comes

204
00:11:10.360 --> 00:11:12.279
<v Speaker 2>down to two people for the most I think most

205
00:11:12.320 --> 00:11:15.960
<v Speaker 2>people agree. Now it's Jack Kilby of Texas Instruments with

206
00:11:16.080 --> 00:11:19.360
<v Speaker 2>a thing he called the hybrid ice, so some discrete

207
00:11:19.399 --> 00:11:24.039
<v Speaker 2>components and some integrated in a containerized package with pins,

208
00:11:24.600 --> 00:11:27.559
<v Speaker 2>and of Robert Nois of Fairschald Semiconductor, who's also the

209
00:11:27.559 --> 00:11:30.399
<v Speaker 2>guy who later goes on to form Intel with his

210
00:11:30.480 --> 00:11:31.519
<v Speaker 2>monolithic ices.

211
00:11:31.799 --> 00:11:35.000
<v Speaker 1>So the integrated circuit means everything is on one ship

212
00:11:35.039 --> 00:11:38.759
<v Speaker 1>with the pins and the transistors are mounted inside that.

213
00:11:38.759 --> 00:11:41.639
<v Speaker 2>That's the idea, and there's a bunch but if you're

214
00:11:41.639 --> 00:11:43.919
<v Speaker 2>looking at just the packaging, So I have a package

215
00:11:43.919 --> 00:11:45.480
<v Speaker 2>with pins on it, and it has a bunch of

216
00:11:45.519 --> 00:11:48.240
<v Speaker 2>stuff in it, and it does a particular task that's

217
00:11:48.320 --> 00:11:53.320
<v Speaker 2>pretty integrated. But then you get into what's actually inside

218
00:11:53.320 --> 00:11:56.600
<v Speaker 2>that package, and you know, Noise is designed with what

219
00:11:56.600 --> 00:11:59.320
<v Speaker 2>they call the monolithic icee is actually a layers of

220
00:12:00.039 --> 00:12:05.240
<v Speaker 2>ustrate silicon crystal that are doped into different potentials so

221
00:12:05.279 --> 00:12:08.120
<v Speaker 2>that they can be etched together to make transistors and

222
00:12:08.159 --> 00:12:11.240
<v Speaker 2>resistors and other components. I get it. Yeah, Killey's approach

223
00:12:11.320 --> 00:12:12.320
<v Speaker 2>was more discreete.

224
00:12:12.080 --> 00:12:16.000
<v Speaker 1>So ICs continued to evolve and get more powerful. But

225
00:12:16.120 --> 00:12:18.480
<v Speaker 1>you're calling that one the first because it was the

226
00:12:18.519 --> 00:12:21.600
<v Speaker 1>first contained integrated.

227
00:12:21.200 --> 00:12:24.159
<v Speaker 2>Well, I called the first really going in ninety sixty

228
00:12:24.200 --> 00:12:26.240
<v Speaker 2>one is when it was first made into a product,

229
00:12:26.360 --> 00:12:30.799
<v Speaker 2>at least briefly, and it was you know, the nexus

230
00:12:30.799 --> 00:12:34.200
<v Speaker 2>of this is in two thousand, Jack Kilby was given

231
00:12:34.240 --> 00:12:37.440
<v Speaker 2>the Nobel Prize in Physics for his quote unquote contributions

232
00:12:37.480 --> 00:12:40.279
<v Speaker 2>integrated circuit and created a huge fuss around all that

233
00:12:40.320 --> 00:12:44.759
<v Speaker 2>because Kilby's design that the hybrid icee doesn't last. Ultimately,

234
00:12:44.799 --> 00:12:47.720
<v Speaker 2>Noises design is what makes integrated circuits to this day.

235
00:12:47.720 --> 00:12:50.720
<v Speaker 2>Although limittedly. The technology has evolved a lot, but in

236
00:12:50.840 --> 00:12:56.720
<v Speaker 2>nineteen sixty one, Texas Instruments started manufacturing a product called

237
00:12:56.759 --> 00:13:02.039
<v Speaker 2>the Multivibrator five h two. Inside of that package, some

238
00:13:02.120 --> 00:13:05.519
<v Speaker 2>of it some silicon substrates, some discrete were two transistors,

239
00:13:05.519 --> 00:13:08.960
<v Speaker 2>four diode, six resistors, and two capacitors to be used

240
00:13:08.960 --> 00:13:12.720
<v Speaker 2>as a waveform generator, which was part of a miniaturized

241
00:13:12.799 --> 00:13:16.039
<v Speaker 2>radio receiver for the US Air Force. Wow. So they

242
00:13:16.080 --> 00:13:18.919
<v Speaker 2>made a few hundred of these and built the test articles,

243
00:13:18.960 --> 00:13:21.720
<v Speaker 2>and it ultimately failed, like in the end, it wasn't

244
00:13:21.720 --> 00:13:26.519
<v Speaker 2>sturdy enough, but it set the big path for integrated

245
00:13:26.559 --> 00:13:28.759
<v Speaker 2>circuits in that kind of ministriization at that time called

246
00:13:28.879 --> 00:13:33.000
<v Speaker 2>molecular electronics because they were so small even though they

247
00:13:33.000 --> 00:13:36.679
<v Speaker 2>were not molecule size in aerospace, and the Air Force

248
00:13:36.720 --> 00:13:38.639
<v Speaker 2>would lead on this for quite a while. It leads

249
00:13:38.679 --> 00:13:41.279
<v Speaker 2>to the ICBM and a bunch of other technology. But

250
00:13:41.480 --> 00:13:43.039
<v Speaker 2>the first, you know, you can kind of hang your

251
00:13:43.080 --> 00:13:46.519
<v Speaker 2>head on, Texas Instruments produce this first thing they called

252
00:13:46.559 --> 00:13:48.840
<v Speaker 2>the integrated circuit, even though it was a design that

253
00:13:48.919 --> 00:13:52.000
<v Speaker 2>ultimately fell into obsolescence in the model ethic ic would

254
00:13:52.000 --> 00:13:54.440
<v Speaker 2>go on from there. Wow big one though, like I said,

255
00:13:54.480 --> 00:13:57.759
<v Speaker 2>it's not simple. Yeah, it is.

256
00:13:57.720 --> 00:14:02.320
<v Speaker 3>Something simpler that we may all remember. Nineteen sixty one,

257
00:14:02.399 --> 00:14:06.840
<v Speaker 3>Phillips introduced the audio cassette, the Compactus that we would

258
00:14:06.879 --> 00:14:11.559
<v Speaker 3>all remember from compact cassette player from our Walkman's Wow

259
00:14:11.600 --> 00:14:12.639
<v Speaker 3>throughout the eighties.

260
00:14:12.879 --> 00:14:15.960
<v Speaker 2>The Walkman's Walkman's is still twenty years away at that point.

261
00:14:16.000 --> 00:14:18.600
<v Speaker 2>But yeah, I know, I know, but wow, you know

262
00:14:18.600 --> 00:14:20.000
<v Speaker 2>what I you know, I pulled up a graphic on

263
00:14:20.039 --> 00:14:23.240
<v Speaker 2>the other day on on the Nakamichi autocassett player because

264
00:14:23.240 --> 00:14:24.679
<v Speaker 2>it was the one that would flip the tape. I

265
00:14:24.759 --> 00:14:25.159
<v Speaker 2>have one.

266
00:14:25.399 --> 00:14:28.039
<v Speaker 1>It's right there. Actually, yeah, I have one. It doesn't

267
00:14:28.039 --> 00:14:30.120
<v Speaker 1>work it, Yeah, flips the tape.

268
00:14:29.919 --> 00:14:32.120
<v Speaker 2>Over, pops the thing would pop out, turn the tape over,

269
00:14:32.159 --> 00:14:33.320
<v Speaker 2>and go back because they didn't want to try and

270
00:14:33.320 --> 00:14:36.559
<v Speaker 2>adjust the head alignments to play both both sides of

271
00:14:36.600 --> 00:14:37.240
<v Speaker 2>the tape. You know.

272
00:14:37.840 --> 00:14:41.159
<v Speaker 1>Yeah, classics. Okay, all right, cool stuff. So I guess

273
00:14:41.279 --> 00:14:44.840
<v Speaker 1>we can introduce Hannis officially. You've heard him talk there.

274
00:14:44.919 --> 00:14:49.639
<v Speaker 1>But Hannis Lauette started his dot net career during college

275
00:14:49.679 --> 00:14:53.279
<v Speaker 1>with Framework one point one. He continued this trend in

276
00:14:53.399 --> 00:14:55.720
<v Speaker 1>his first jobs and has been using dot net ever

277
00:14:55.879 --> 00:15:00.000
<v Speaker 1>since to deliver projects. For many different clients. He's always

278
00:15:00.000 --> 00:15:02.879
<v Speaker 1>has had a passion for back end development in his projects.

279
00:15:02.919 --> 00:15:07.159
<v Speaker 1>He's always gravitated to problems that involves scaling, architecture and complexity.

280
00:15:07.679 --> 00:15:09.879
<v Speaker 1>Because of that, he developed a love for event driven

281
00:15:09.960 --> 00:15:13.840
<v Speaker 1>architectures that fits with what we're going to talk about.

282
00:15:14.720 --> 00:15:19.399
<v Speaker 1>Since twenty eleven, surprise, surprise, Yeah, yeah, Since twenty eleven,

283
00:15:19.440 --> 00:15:21.840
<v Speaker 1>he's been working for ACES in Belgium.

284
00:15:21.919 --> 00:15:22.600
<v Speaker 2>Is that how you say it?

285
00:15:22.759 --> 00:15:28.919
<v Speaker 1>Yes, ax Xes currently as principal consultant. Aside from his

286
00:15:29.000 --> 00:15:32.399
<v Speaker 1>technical role, Hannas has always been driven by helping other

287
00:15:32.480 --> 00:15:36.879
<v Speaker 1>developers grow. He actively coaches people, runs workshops, gives conference talks,

288
00:15:37.440 --> 00:15:40.240
<v Speaker 1>and is a course author on dome Train is free time.

289
00:15:40.279 --> 00:15:43.080
<v Speaker 1>You can find him on stage playing guitar for line Breakers,

290
00:15:43.519 --> 00:15:47.159
<v Speaker 1>The line Breakers, I guess that's the line Breaker Dylan's band.

291
00:15:47.320 --> 00:15:47.480
<v Speaker 2>Right.

292
00:15:47.919 --> 00:15:50.360
<v Speaker 1>When he's not doing things with his three children, he

293
00:15:50.440 --> 00:15:54.960
<v Speaker 1>builds guitars, plays chess badly in parentheses, I didn't write this,

294
00:15:55.440 --> 00:15:59.960
<v Speaker 1>and loves tasting whiskey and who doesn't to keep moving.

295
00:16:00.120 --> 00:16:03.039
<v Speaker 1>He loves to mountain, bike or swim. All right, Hannas,

296
00:16:03.600 --> 00:16:06.759
<v Speaker 1>The floor is All of those things are true. Wow, yeah,

297
00:16:07.360 --> 00:16:09.799
<v Speaker 1>And the floor is yours. I'm sorry, I'm pretty sure

298
00:16:09.879 --> 00:16:10.519
<v Speaker 1>you wrote this.

299
00:16:11.159 --> 00:16:13.639
<v Speaker 3>I'm just yeah, I kind I kind of sent this

300
00:16:13.879 --> 00:16:16.679
<v Speaker 3>to Krawl in events. But hey, thanks for having me,

301
00:16:16.960 --> 00:16:19.879
<v Speaker 3>Thanks for having show. I'm embarrassed almost that we haven't

302
00:16:19.879 --> 00:16:22.080
<v Speaker 3>had you before at this point. Well, this is your

303
00:16:22.120 --> 00:16:24.360
<v Speaker 3>first appearance on dot Ney Rocks, even though we've hung

304
00:16:24.440 --> 00:16:28.639
<v Speaker 3>out at conferences and seen each other talk. Yeah many times.

305
00:16:29.039 --> 00:16:30.960
<v Speaker 3>So welcome, Thank you, Thanks for having.

306
00:16:30.840 --> 00:16:34.360
<v Speaker 1>The floor is yours? You're going to talk about event sourcing.

307
00:16:34.679 --> 00:16:38.080
<v Speaker 1>I guess maybe other things, maybe other shoes. Yeah, let's

308
00:16:38.080 --> 00:16:40.600
<v Speaker 1>see where the conversation goes. Should we start with the

309
00:16:40.600 --> 00:16:43.000
<v Speaker 1>elevator pitch? What is event sourcing? If you've been hiding

310
00:16:43.080 --> 00:16:44.879
<v Speaker 1>under a rock for the last fifteen.

311
00:16:44.600 --> 00:16:50.879
<v Speaker 3>Years, okay, elevator pitch. We have been using systems like

312
00:16:50.960 --> 00:16:54.799
<v Speaker 3>the default when we develop software systems seems to still

313
00:16:54.879 --> 00:17:00.200
<v Speaker 3>be to use normalized databases. And basically, when you or

314
00:17:00.679 --> 00:17:04.680
<v Speaker 3>state in a normalized database, what you're basically doing is

315
00:17:05.519 --> 00:17:09.200
<v Speaker 3>storing the state of the system right now, and you

316
00:17:09.359 --> 00:17:12.799
<v Speaker 3>lose all of the history that came before it. And

317
00:17:12.920 --> 00:17:16.119
<v Speaker 3>with event sourcing, what we actually try to do is

318
00:17:16.279 --> 00:17:19.799
<v Speaker 3>the opposite. We store all of the events that lead

319
00:17:20.440 --> 00:17:22.960
<v Speaker 3>up to the current state, which means that if we

320
00:17:23.160 --> 00:17:26.839
<v Speaker 3>replay the events, we can recalculate the state. If we

321
00:17:26.920 --> 00:17:31.400
<v Speaker 3>have the state, we cannot recalculate the history because that's gone. Basically,

322
00:17:31.440 --> 00:17:35.640
<v Speaker 3>if you switch your philosophy from storing state to storing events,

323
00:17:36.200 --> 00:17:39.319
<v Speaker 3>you enable a whole lot of other things in your

324
00:17:39.519 --> 00:17:43.240
<v Speaker 3>architectures as well. But the essence of event sourcing is

325
00:17:43.319 --> 00:17:46.440
<v Speaker 3>basically that you're going to store events instead of the

326
00:17:46.559 --> 00:17:47.440
<v Speaker 3>projected safe.

327
00:17:47.279 --> 00:17:50.039
<v Speaker 1>You neveric going to update, You're going to add a

328
00:17:50.160 --> 00:17:54.160
<v Speaker 1>new record with the changes. Yes, some people have asked

329
00:17:54.200 --> 00:17:57.000
<v Speaker 1>this by adding a couple of fields to every table.

330
00:17:57.200 --> 00:18:01.240
<v Speaker 1>You know, update user and update date. You know, insert date,

331
00:18:01.359 --> 00:18:02.440
<v Speaker 1>insert users.

332
00:18:02.200 --> 00:18:04.000
<v Speaker 3>Like auditing fields and stuff like.

333
00:18:04.160 --> 00:18:06.039
<v Speaker 1>Yeah, like auditing fields, and that's only good for the

334
00:18:06.119 --> 00:18:08.119
<v Speaker 1>last change that was made.

335
00:18:08.519 --> 00:18:08.720
<v Speaker 2>Yeah.

336
00:18:10.559 --> 00:18:15.160
<v Speaker 3>The whole idea for me that makes this interesting is

337
00:18:15.279 --> 00:18:19.400
<v Speaker 3>if we look at where database normalization comes from. A

338
00:18:19.480 --> 00:18:24.039
<v Speaker 3>lot of that was conceived when the first Squel standards

339
00:18:24.119 --> 00:18:29.720
<v Speaker 3>were developed in the nineteen eighties. And what's relevant for

340
00:18:30.000 --> 00:18:33.519
<v Speaker 3>that time is that your average hard drive cost a

341
00:18:33.559 --> 00:18:36.799
<v Speaker 3>lot more than the computer that it was attached to, Right,

342
00:18:37.279 --> 00:18:40.839
<v Speaker 3>So normalizing had a couple of benefits. First of all,

343
00:18:41.079 --> 00:18:45.079
<v Speaker 3>it made your data consistent and you try to avoid

344
00:18:45.279 --> 00:18:51.519
<v Speaker 3>any update conflicts or any data manipulation concurrency issues that

345
00:18:51.599 --> 00:18:54.759
<v Speaker 3>you might have. You would also store every bit of

346
00:18:54.920 --> 00:18:58.799
<v Speaker 3>information only once, which conserved.

347
00:18:58.359 --> 00:19:01.920
<v Speaker 2>Disk space back back when that was important.

348
00:19:01.799 --> 00:19:04.480
<v Speaker 3>Right back when that was important. But nowadays on your

349
00:19:04.599 --> 00:19:08.160
<v Speaker 3>cloud build, disk space is not typically the thing that

350
00:19:09.480 --> 00:19:15.920
<v Speaker 3>most like CPU cycles and and memory usage and bandwidth

351
00:19:16.000 --> 00:19:18.000
<v Speaker 3>like that's that's all going to be way more expensive

352
00:19:18.039 --> 00:19:19.480
<v Speaker 3>than than your disk space.

353
00:19:19.920 --> 00:19:20.119
<v Speaker 2>Yeah.

354
00:19:20.440 --> 00:19:25.000
<v Speaker 3>But what we have, I think in our industry maybe

355
00:19:26.359 --> 00:19:28.480
<v Speaker 3>ingrained in our brains a little bit, is all the

356
00:19:28.599 --> 00:19:32.079
<v Speaker 3>tradeoffs that we've made to normalize our databases, because it

357
00:19:32.200 --> 00:19:35.279
<v Speaker 3>comes with a whole bunch of tradeoffs, but we have

358
00:19:35.599 --> 00:19:39.240
<v Speaker 3>just learned to work work around, right, all of those tradeoffs.

359
00:19:39.519 --> 00:19:43.680
<v Speaker 1>Sure, So what are those trade offs with normalized relational

360
00:19:43.759 --> 00:19:46.039
<v Speaker 1>database that we might have forgotten about?

361
00:19:46.240 --> 00:19:50.599
<v Speaker 3>Well, the first thing that comes to mind is you

362
00:19:51.240 --> 00:19:55.400
<v Speaker 3>are sacrificing CPU cycles to be able to store your

363
00:19:56.079 --> 00:19:59.720
<v Speaker 3>data in a normalized shape, because whenever you have to

364
00:20:00.640 --> 00:20:03.400
<v Speaker 3>fetch a meaningful amount of data to do work on,

365
00:20:03.519 --> 00:20:07.720
<v Speaker 3>you're often hitting multiple tables, which means that you're doing joints,

366
00:20:08.799 --> 00:20:13.359
<v Speaker 3>and joints are expensive. Yeah, and the problem with doing

367
00:20:13.480 --> 00:20:17.480
<v Speaker 3>joints in a typical relational database is you also have

368
00:20:17.680 --> 00:20:21.960
<v Speaker 3>no way of easily scaling that compute because it's going

369
00:20:22.039 --> 00:20:24.480
<v Speaker 3>to happen in your database engine and you cannot just

370
00:20:24.640 --> 00:20:27.759
<v Speaker 3>like put a cluster of nodes in front of it

371
00:20:27.880 --> 00:20:31.039
<v Speaker 3>that are going to do the joints for you. So

372
00:20:31.200 --> 00:20:33.759
<v Speaker 3>that's that's the first thing. You're sacrificing a bunch of

373
00:20:33.839 --> 00:20:40.519
<v Speaker 3>compute to make that happen, and you introduce locking problems

374
00:20:41.480 --> 00:20:43.640
<v Speaker 3>because whenever you touch your record, you have to make

375
00:20:43.680 --> 00:20:47.960
<v Speaker 3>sure that there's no race conditions and no threading problems, so.

376
00:20:48.359 --> 00:20:51.240
<v Speaker 1>You have to use transactions in case there are problems,

377
00:20:51.279 --> 00:20:52.240
<v Speaker 1>and then you roll it back.

378
00:20:52.359 --> 00:20:54.440
<v Speaker 3>Yeah, so either you're going to deal with that with

379
00:20:54.559 --> 00:20:57.759
<v Speaker 3>optimistic concurrency or with pessimistic concurrency, but at some point

380
00:20:57.839 --> 00:21:01.279
<v Speaker 3>you are going to deal with some kind of because

381
00:21:01.559 --> 00:21:04.400
<v Speaker 3>concurrency issues that you're going to solve in your database

382
00:21:04.440 --> 00:21:08.279
<v Speaker 3>as well, because you're only storing that one bit of state,

383
00:21:08.359 --> 00:21:10.359
<v Speaker 3>and everybody that touches that is going to have to

384
00:21:10.440 --> 00:21:14.039
<v Speaker 3>touch the same record and update it or deleted or whatever.

385
00:21:13.839 --> 00:21:14.640
<v Speaker 2>That we want to do with it.

386
00:21:15.839 --> 00:21:19.200
<v Speaker 3>And we've taken all of that for granted, because if

387
00:21:19.240 --> 00:21:22.039
<v Speaker 3>we look at even the modern versions of dot Net.

388
00:21:22.200 --> 00:21:27.240
<v Speaker 3>The first stack that they brought to Core included entity framework,

389
00:21:27.240 --> 00:21:31.279
<v Speaker 3>and I'm a huge enity framework fan. But part of

390
00:21:31.599 --> 00:21:34.319
<v Speaker 3>why we have or rems is because we try to

391
00:21:34.359 --> 00:21:36.839
<v Speaker 3>solve some of the issues that you have with this

392
00:21:37.039 --> 00:21:40.920
<v Speaker 3>way of thinking, because almost never are you in a

393
00:21:40.960 --> 00:21:44.359
<v Speaker 3>complex application are you touching just a single table. You

394
00:21:44.519 --> 00:21:49.960
<v Speaker 3>usually need a whole graph of different related tables, a

395
00:21:50.119 --> 00:21:54.240
<v Speaker 3>parent entity with some with some related entities that you're

396
00:21:54.240 --> 00:21:56.480
<v Speaker 3>all fetching and then updating and then writing back and

397
00:21:56.640 --> 00:21:58.480
<v Speaker 3>all that sort of stuff. And that's why you have

398
00:21:58.839 --> 00:22:01.599
<v Speaker 3>ORMs to make that a lot easier to do in code.

399
00:22:02.559 --> 00:22:05.519
<v Speaker 3>But all of that is still working around the idea

400
00:22:05.640 --> 00:22:09.240
<v Speaker 3>that we're only storing the truth at this very moment

401
00:22:09.440 --> 00:22:10.720
<v Speaker 3>in our relational database.

402
00:22:11.680 --> 00:22:14.880
<v Speaker 2>And part of storing the truth is actually creating data

403
00:22:14.920 --> 00:22:17.599
<v Speaker 2>structures that keep the truth. You know, the classic one

404
00:22:17.720 --> 00:22:22.440
<v Speaker 2>is yes, only one address per customer, and then they move, Yeah.

405
00:22:22.440 --> 00:22:25.480
<v Speaker 3>Like you lose the history, Like what was the state

406
00:22:25.599 --> 00:22:30.400
<v Speaker 3>of this entity last week, last year, or whatever. We've

407
00:22:30.480 --> 00:22:36.519
<v Speaker 3>actually lost that. And that's where the whole idea of

408
00:22:37.000 --> 00:22:41.920
<v Speaker 3>event sourcing comes from, is that if instead of storing

409
00:22:42.039 --> 00:22:47.559
<v Speaker 3>the resulting state, we instead store all the business events

410
00:22:47.680 --> 00:22:50.920
<v Speaker 3>that lead up to this state becoming what it is.

411
00:22:51.920 --> 00:22:54.240
<v Speaker 3>We can always recreate the state because the state is

412
00:22:54.400 --> 00:22:56.680
<v Speaker 3>just very cheaply replaying the events.

413
00:22:57.200 --> 00:22:57.319
<v Speaker 2>Right.

414
00:22:57.680 --> 00:23:00.799
<v Speaker 3>And in event sourcing, we assume that every event that

415
00:23:00.920 --> 00:23:05.240
<v Speaker 3>we have written to our event stream what's true at

416
00:23:05.279 --> 00:23:07.279
<v Speaker 3>the time that it was created, so we don't have

417
00:23:07.400 --> 00:23:10.519
<v Speaker 3>to doubt it, right, this was the truth, which means

418
00:23:10.599 --> 00:23:13.839
<v Speaker 3>that your replay mechanism is actually going to be relatively

419
00:23:13.960 --> 00:23:16.880
<v Speaker 3>cheap because what you usually have is you have your

420
00:23:16.960 --> 00:23:19.519
<v Speaker 3>root entity with all of its dependencies, and you're replaying

421
00:23:19.559 --> 00:23:23.119
<v Speaker 3>all the events on that and you don't have to

422
00:23:23.200 --> 00:23:25.279
<v Speaker 3>doubt the event. So a lot of these methods are

423
00:23:25.440 --> 00:23:28.079
<v Speaker 3>just going to be setting a couple of fields, a

424
00:23:28.160 --> 00:23:30.359
<v Speaker 3>couple of properties that you're going to fill out or

425
00:23:30.440 --> 00:23:34.079
<v Speaker 3>modify or whatever, and you can replay thousands of events

426
00:23:34.359 --> 00:23:36.519
<v Speaker 3>in just a couple of milliseconds. But the cool thing

427
00:23:36.559 --> 00:23:39.400
<v Speaker 3>about that is that replaying is not happening in your

428
00:23:39.480 --> 00:23:43.759
<v Speaker 3>database engine, is right. It's happening somewhere outside of it,

429
00:23:44.000 --> 00:23:46.640
<v Speaker 3>in your net code, which is easier to distribute.

430
00:23:46.720 --> 00:23:48.640
<v Speaker 1>So the light bulb just went off because I was

431
00:23:48.680 --> 00:23:53.240
<v Speaker 1>asking myself, when you're talking about the problems that it

432
00:23:53.400 --> 00:23:58.400
<v Speaker 1>solves in this whole you know, multiple joints and everything. Well,

433
00:23:58.519 --> 00:24:01.960
<v Speaker 1>now you're really kind of talking about flat document, right

434
00:24:02.240 --> 00:24:05.599
<v Speaker 1>that instead of having all these joints. So is event

435
00:24:05.720 --> 00:24:10.319
<v Speaker 1>sourcing something that you can use alongside a relational database,

436
00:24:10.480 --> 00:24:14.839
<v Speaker 1>like your events are separate from the relational database? Or

437
00:24:15.880 --> 00:24:19.599
<v Speaker 1>do you remove the hierarchy of a relational database when

438
00:24:19.599 --> 00:24:21.200
<v Speaker 1>you're using events sourcing?

439
00:24:21.440 --> 00:24:26.000
<v Speaker 3>Well, typically what an event stream looks like is an

440
00:24:26.000 --> 00:24:31.160
<v Speaker 3>append only store. You're going to append new events to

441
00:24:31.319 --> 00:24:33.880
<v Speaker 3>the store, and all of these events happen usually in

442
00:24:33.960 --> 00:24:37.240
<v Speaker 3>the scope of a certain stream ID or a certain

443
00:24:37.279 --> 00:24:39.160
<v Speaker 3>aggregate I D or whatever you want to call it,

444
00:24:39.960 --> 00:24:45.000
<v Speaker 3>which typically like what orders, it kind of points to

445
00:24:45.160 --> 00:24:48.359
<v Speaker 3>the root and dy that this event happened for. Right,

446
00:24:48.559 --> 00:24:53.960
<v Speaker 3>So if you have a certain order number, like customer

447
00:24:54.119 --> 00:24:57.799
<v Speaker 3>Richard is placing an order on my website to order

448
00:24:58.039 --> 00:25:00.839
<v Speaker 3>a new guitar, and he's going through the whole process

449
00:25:00.880 --> 00:25:02.599
<v Speaker 3>of specking said.

450
00:25:02.440 --> 00:25:05.720
<v Speaker 2>Guitar, it'll be a tuba though for Richard, totally.

451
00:25:05.519 --> 00:25:13.519
<v Speaker 3>Totally hypothetical, and we could we could basically model Richard's

452
00:25:13.759 --> 00:25:16.920
<v Speaker 3>configuration process of the guitar in multiple events. Now, he

453
00:25:17.000 --> 00:25:18.880
<v Speaker 3>selected the color and he did this and he did

454
00:25:18.960 --> 00:25:22.400
<v Speaker 3>that and whatever, and every event is going to point

455
00:25:22.480 --> 00:25:27.000
<v Speaker 3>to Richard's order, which means that if you Carl at

456
00:25:27.039 --> 00:25:30.519
<v Speaker 3>the same time are configuring a guitar as well, those

457
00:25:30.559 --> 00:25:34.440
<v Speaker 3>two aggregates will have nothing that has that could potentially

458
00:25:34.599 --> 00:25:38.039
<v Speaker 3>have a side effect on one another, because those will

459
00:25:38.119 --> 00:25:42.119
<v Speaker 3>be two separate aggregates or two separate streams, if you will.

460
00:25:43.480 --> 00:25:46.720
<v Speaker 3>And when we append everything to the store, we have

461
00:25:46.799 --> 00:25:49.200
<v Speaker 3>a couple of things that play into the key. One

462
00:25:49.440 --> 00:25:52.720
<v Speaker 3>is the aggregate that event happened for, but also the

463
00:25:52.799 --> 00:25:55.039
<v Speaker 3>sequence number. And the sequence number is what's going to

464
00:25:55.079 --> 00:25:58.039
<v Speaker 3>help us with concurrency, because at some point you're gonna

465
00:25:58.119 --> 00:26:00.799
<v Speaker 3>have in an event source system, you're gonna want to

466
00:26:00.839 --> 00:26:03.559
<v Speaker 3>scale out, you want to go You're gonna want to

467
00:26:03.599 --> 00:26:06.559
<v Speaker 3>have a way to deal with multiple commands coming in

468
00:26:06.680 --> 00:26:10.000
<v Speaker 3>on the same aggregate because they're all gonna spawn events

469
00:26:10.039 --> 00:26:12.400
<v Speaker 3>on the same aggregate and you don't want them to

470
00:26:12.559 --> 00:26:17.160
<v Speaker 3>be written to the database without knowing about the other

471
00:26:17.279 --> 00:26:20.519
<v Speaker 3>events that might have happened in the mean one. So

472
00:26:20.720 --> 00:26:23.440
<v Speaker 3>the the the stream idea or the aggregate idea, and

473
00:26:23.480 --> 00:26:25.519
<v Speaker 3>the sequence number that's going to be the important bit

474
00:26:25.759 --> 00:26:29.079
<v Speaker 3>of storing new events and events. The payload is just

475
00:26:29.200 --> 00:26:31.839
<v Speaker 3>an object something that we serialize, and it could be

476
00:26:32.319 --> 00:26:35.000
<v Speaker 3>several it could be as deep as we want, it

477
00:26:35.079 --> 00:26:37.960
<v Speaker 3>could be a whole object graph. It's just a single

478
00:26:38.000 --> 00:26:40.799
<v Speaker 3>object that we have to be able to de serialize again.

479
00:26:40.839 --> 00:26:43.359
<v Speaker 3>And that's that's basically the essence of what you need.

480
00:26:43.839 --> 00:26:45.440
<v Speaker 3>Simplest event stream you could build.

481
00:26:45.759 --> 00:26:49.440
<v Speaker 1>So let's say the first person to log on after midnight. Right,

482
00:26:50.039 --> 00:26:53.400
<v Speaker 1>Let's say you're going to get all the data from

483
00:26:53.440 --> 00:26:57.160
<v Speaker 1>your relational database, et cetera and make an event that's like, hey,

484
00:26:57.279 --> 00:26:58.519
<v Speaker 1>this is the first event today.

485
00:27:00.400 --> 00:27:00.559
<v Speaker 2>Is that?

486
00:27:00.799 --> 00:27:03.119
<v Speaker 1>Is that the idea, and then all the modifications that

487
00:27:03.240 --> 00:27:05.799
<v Speaker 1>happen to it just work with that those event streams

488
00:27:06.359 --> 00:27:08.599
<v Speaker 1>and when you when you're doing updates and everything.

489
00:27:08.759 --> 00:27:12.400
<v Speaker 3>No, the idea is that the idea is that if

490
00:27:12.519 --> 00:27:16.880
<v Speaker 3>you need that root entity, instead of fetching that from

491
00:27:16.920 --> 00:27:20.240
<v Speaker 3>the database, you were actually going to fetch all of

492
00:27:20.279 --> 00:27:24.680
<v Speaker 3>the events that have happened on that entity and then

493
00:27:24.759 --> 00:27:27.000
<v Speaker 3>you're going to replay them in code. Okay, and that

494
00:27:27.079 --> 00:27:29.200
<v Speaker 3>will bring you up to speed to the point where

495
00:27:29.240 --> 00:27:30.880
<v Speaker 3>we are. But where do we start? I mean we

496
00:27:31.000 --> 00:27:33.240
<v Speaker 3>start with a database, right that has on a data

497
00:27:33.279 --> 00:27:36.079
<v Speaker 3>in it. Yeah, well, you could know your database could

498
00:27:36.240 --> 00:27:38.920
<v Speaker 3>just be a single table with all of your events

499
00:27:38.960 --> 00:27:39.079
<v Speaker 3>in it.

500
00:27:39.279 --> 00:27:41.440
<v Speaker 2>Oh all right, so this is what I was asking before.

501
00:27:41.960 --> 00:27:46.440
<v Speaker 1>You get rid of your relational database in but you

502
00:27:46.559 --> 00:27:50.359
<v Speaker 1>still have your objects in memory, right. You define your

503
00:27:50.400 --> 00:27:53.880
<v Speaker 1>memory that you're going to turn into Jason yes in

504
00:27:54.000 --> 00:27:55.759
<v Speaker 1>story in your event database.

505
00:27:55.640 --> 00:27:58.920
<v Speaker 3>Whenever the live cycle of how, let's say, an API

506
00:27:59.039 --> 00:28:01.480
<v Speaker 3>call comes in. I think that's the easiest way to

507
00:28:01.839 --> 00:28:05.319
<v Speaker 3>reason about. It's like an API call comes in typically

508
00:28:05.400 --> 00:28:08.519
<v Speaker 3>a command something you want your system to do, and

509
00:28:08.640 --> 00:28:11.119
<v Speaker 3>you're going to want to execute that. Usually your commands

510
00:28:11.119 --> 00:28:14.160
<v Speaker 3>are going to touch a certain root entity. If I'm

511
00:28:14.200 --> 00:28:17.680
<v Speaker 3>going to update the address for Carl, the root entity

512
00:28:17.799 --> 00:28:19.279
<v Speaker 3>is going to be Carl, right, So I'm going to

513
00:28:19.319 --> 00:28:22.880
<v Speaker 3>have to fetch your date details, and then your current

514
00:28:23.000 --> 00:28:25.720
<v Speaker 3>state is going to dictate what the result of the

515
00:28:25.759 --> 00:28:28.240
<v Speaker 3>command is going to be, because what your current address

516
00:28:28.720 --> 00:28:31.920
<v Speaker 3>is might affect what happens with this address update. So

517
00:28:32.079 --> 00:28:34.160
<v Speaker 3>in order to get your current state, I'm going to

518
00:28:34.200 --> 00:28:36.880
<v Speaker 3>fetch all of the events that have happened on entity Carl,

519
00:28:37.400 --> 00:28:40.559
<v Speaker 3>replay them, get your current state, then run my command,

520
00:28:40.640 --> 00:28:42.720
<v Speaker 3>and then append the new events to the stream.

521
00:28:42.759 --> 00:28:44.640
<v Speaker 2>Again. Yep, I get that. I get that.

522
00:28:44.799 --> 00:28:47.559
<v Speaker 1>I guess what I didn't get was that we're completely

523
00:28:47.680 --> 00:28:51.759
<v Speaker 1>replacing our relational database well in this with a document

524
00:28:52.039 --> 00:28:53.720
<v Speaker 1>centric database.

525
00:28:53.400 --> 00:28:58.720
<v Speaker 3>For the events sourced stuff. Yes, yes, And what does

526
00:28:58.920 --> 00:29:02.279
<v Speaker 3>happen a lot is that you will still have relational

527
00:29:02.400 --> 00:29:05.160
<v Speaker 3>tables with some reference data and so on. There's no

528
00:29:05.519 --> 00:29:11.119
<v Speaker 3>point in making every single entity in your entire system

529
00:29:11.240 --> 00:29:13.759
<v Speaker 3>events sourced. I mean, you don't want to hurt yourself

530
00:29:13.839 --> 00:29:16.799
<v Speaker 3>too much. And so if you have a table that

531
00:29:17.079 --> 00:29:20.720
<v Speaker 3>just has a list of countries or whatever, you could

532
00:29:20.799 --> 00:29:22.839
<v Speaker 3>make that event sourced if that is part of your

533
00:29:22.920 --> 00:29:26.759
<v Speaker 3>core domain. Usually that kind of stuff is reference data

534
00:29:26.799 --> 00:29:30.799
<v Speaker 3>and you can just keep that in relational tables. But

535
00:29:30.960 --> 00:29:33.519
<v Speaker 3>when it comes to the entities where you're doing you're

536
00:29:33.559 --> 00:29:37.759
<v Speaker 3>running your actual domain logic, you're going to basically want

537
00:29:38.039 --> 00:29:41.720
<v Speaker 3>to get your truth from the events. That's the whole idea.

538
00:29:42.039 --> 00:29:43.960
<v Speaker 1>Yeah, that's great, and this is a great place to

539
00:29:44.039 --> 00:29:46.480
<v Speaker 1>pause for a break, So we'll be right back after

540
00:29:46.559 --> 00:29:51.160
<v Speaker 1>these very important messages don't go away. Did you know

541
00:29:51.279 --> 00:29:54.640
<v Speaker 1>you can easily migrate asp net web apps to Windows

542
00:29:54.720 --> 00:29:59.119
<v Speaker 1>containers on AWS. Use the app to Container tool to

543
00:29:59.279 --> 00:30:02.960
<v Speaker 1>container eye is your iis websites and deployed to AWS

544
00:30:03.160 --> 00:30:08.240
<v Speaker 1>managed container services with or without Kubernetes. Find out more

545
00:30:08.240 --> 00:30:12.880
<v Speaker 1>about app to container at aws dot Amazon dot Com, slash,

546
00:30:12.960 --> 00:30:19.960
<v Speaker 1>dot net, slash modernize, and we're back. It's dot net Rocks.

547
00:30:20.000 --> 00:30:22.680
<v Speaker 1>I'm Carl Franklin, an amateur Campbell, and we're talking to

548
00:30:22.759 --> 00:30:24.720
<v Speaker 1>Hanness Lowett about event sourcing.

549
00:30:25.039 --> 00:30:28.319
<v Speaker 2>You know, I'm reminded that the relational Databases developer reporting

550
00:30:29.000 --> 00:30:31.839
<v Speaker 2>and it got sold on transactional velocity because that was

551
00:30:31.839 --> 00:30:35.400
<v Speaker 2>easier to sell. But there is a there's a case

552
00:30:35.440 --> 00:30:38.960
<v Speaker 2>to be made for after an event is logged, if

553
00:30:39.039 --> 00:30:41.279
<v Speaker 2>you think it's reportable or it's a you know, falls

554
00:30:41.279 --> 00:30:44.039
<v Speaker 2>in a certain class of event, then you do decompose

555
00:30:44.119 --> 00:30:48.400
<v Speaker 2>it asynchronously, not making the customer way into relational data

556
00:30:48.480 --> 00:30:51.160
<v Speaker 2>tables for reporting purposes, because.

557
00:30:51.000 --> 00:30:53.759
<v Speaker 3>That's what we call projections. Yeah, and so what you

558
00:30:53.880 --> 00:30:58.799
<v Speaker 3>basically do if you think about your c qres architecture,

559
00:30:58.880 --> 00:31:00.640
<v Speaker 3>Let's say that you have a comment side of your

560
00:31:00.720 --> 00:31:03.799
<v Speaker 3>system where all of the business logics is triggered when

561
00:31:04.880 --> 00:31:08.079
<v Speaker 3>other systems or users Q commands, and you have your

562
00:31:08.160 --> 00:31:12.359
<v Speaker 3>red side of the system where you're querrying data. It

563
00:31:12.559 --> 00:31:17.519
<v Speaker 3>makes sense to prepare some data for querying because if

564
00:31:17.559 --> 00:31:21.559
<v Speaker 3>you regularly need to pull a list of all of

565
00:31:21.640 --> 00:31:24.759
<v Speaker 3>your customers with their current addresses. That's going to be

566
00:31:24.960 --> 00:31:27.599
<v Speaker 3>very expensive to run if you have to project it

567
00:31:27.680 --> 00:31:30.559
<v Speaker 3>from the source events, because what you're basically going to

568
00:31:30.640 --> 00:31:33.799
<v Speaker 3>have to do is get all of your users and

569
00:31:33.920 --> 00:31:36.240
<v Speaker 3>project them all one by one until you have the

570
00:31:36.319 --> 00:31:40.000
<v Speaker 3>list of addresses. As way too expensive. So basically, whenever

571
00:31:40.240 --> 00:31:46.880
<v Speaker 3>we queue, whenever we save an address changed event, that's

572
00:31:46.920 --> 00:31:50.160
<v Speaker 3>going to update that table. So we have little bit

573
00:31:50.279 --> 00:31:52.519
<v Speaker 3>of bits of business logic that are going to be

574
00:31:52.720 --> 00:31:59.200
<v Speaker 3>running and listening to certain events and then updating projected tables. Now,

575
00:31:59.279 --> 00:32:01.839
<v Speaker 3>the big advantage of doing that is that also that

576
00:32:02.279 --> 00:32:06.400
<v Speaker 3>is relatively inexpensive. You can look at the contents of

577
00:32:06.480 --> 00:32:08.759
<v Speaker 3>your event and you know, okay, it's this entity. This

578
00:32:08.920 --> 00:32:11.599
<v Speaker 3>is talking about Carl, and Carl has new address. So

579
00:32:11.640 --> 00:32:14.400
<v Speaker 3>all I have to do is without really thinking, because

580
00:32:14.400 --> 00:32:16.240
<v Speaker 3>I don't have to check the validity of the event

581
00:32:16.359 --> 00:32:19.839
<v Speaker 3>that has happened when we executed command, so I don't

582
00:32:19.880 --> 00:32:22.359
<v Speaker 3>have to recheck that. I can just take that and

583
00:32:22.440 --> 00:32:25.920
<v Speaker 3>then update the view or at the table that we

584
00:32:26.039 --> 00:32:28.359
<v Speaker 3>are going to querry on the query side of our system,

585
00:32:28.440 --> 00:32:31.000
<v Speaker 3>and we can keep that in sync. And the cool

586
00:32:31.079 --> 00:32:34.279
<v Speaker 3>thing about these projections is if we want, we can

587
00:32:34.440 --> 00:32:38.720
<v Speaker 3>rebuild them so whenever the logic to go from source

588
00:32:38.839 --> 00:32:42.480
<v Speaker 3>events to whatever projected data we want to have. Whenever

589
00:32:42.640 --> 00:32:46.799
<v Speaker 3>that changes, we just throw away the table and repopulate it.

590
00:32:46.880 --> 00:32:51.079
<v Speaker 3>We replay the stream from the beginning of time and like,

591
00:32:51.240 --> 00:32:54.640
<v Speaker 3>if you have a system with millions and millions of events, like,

592
00:32:54.759 --> 00:32:57.400
<v Speaker 3>some of these projections might take a while to rebuild,

593
00:32:57.480 --> 00:33:00.880
<v Speaker 3>so there are techniques to do that at a synchroncy

594
00:33:01.079 --> 00:33:05.000
<v Speaker 3>before you replace the table, that sort of stuff. But

595
00:33:05.160 --> 00:33:09.720
<v Speaker 3>you can basically get an updated view of your query

596
00:33:09.880 --> 00:33:12.839
<v Speaker 3>data by just rerunning the events and replaying them because

597
00:33:12.839 --> 00:33:15.799
<v Speaker 3>you still have everything that has happened in the system

598
00:33:15.960 --> 00:33:16.480
<v Speaker 3>ever since.

599
00:33:16.720 --> 00:33:19.039
<v Speaker 2>Yeah, so it means you could always regenerate any aggregate

600
00:33:19.319 --> 00:33:21.759
<v Speaker 2>resulting data set one or the other at least validate

601
00:33:21.799 --> 00:33:24.519
<v Speaker 2>whether it's correct or not. But my concern is as

602
00:33:24.559 --> 00:33:26.519
<v Speaker 2>your number of events starts to build up, finding out

603
00:33:26.599 --> 00:33:28.960
<v Speaker 2>how many orders did we have last month can get costly.

604
00:33:29.200 --> 00:33:32.240
<v Speaker 3>Well, not if you have a projection that updates that

605
00:33:32.519 --> 00:33:36.519
<v Speaker 3>view on the floor right right. If your projection is

606
00:33:36.640 --> 00:33:39.400
<v Speaker 3>caught up and you're not changing the way that that

607
00:33:39.519 --> 00:33:43.440
<v Speaker 3>projection works. Theory, you should not have to rebuild it.

608
00:33:43.599 --> 00:33:45.079
<v Speaker 2>So it should always be correct.

609
00:33:45.559 --> 00:33:49.319
<v Speaker 3>It should always be correct, So you can you can

610
00:33:49.400 --> 00:33:52.200
<v Speaker 3>flip this around. You could have a projection for every

611
00:33:52.359 --> 00:33:55.720
<v Speaker 3>query endpoint on your querry API that hits a single

612
00:33:55.799 --> 00:33:58.440
<v Speaker 3>table on an index, and you can have that table

613
00:33:58.519 --> 00:34:02.480
<v Speaker 3>populated from your event stream with a dedicated projection just

614
00:34:02.559 --> 00:34:03.200
<v Speaker 3>for that table.

615
00:34:03.680 --> 00:34:07.359
<v Speaker 2>But I appreciate that we're both saying should because things

616
00:34:07.440 --> 00:34:10.159
<v Speaker 2>do go wrong, but can also be fixed.

617
00:34:10.360 --> 00:34:12.719
<v Speaker 3>Of course, it can be fixed, and that's that's the

618
00:34:12.760 --> 00:34:17.599
<v Speaker 3>big advantage. Because you have the whole history, you you

619
00:34:17.880 --> 00:34:22.199
<v Speaker 3>can rebuild anything. And in theory, like one of the

620
00:34:22.280 --> 00:34:24.960
<v Speaker 3>examples that's often used is okay, you can you can

621
00:34:25.119 --> 00:34:29.599
<v Speaker 3>generate new insights from past events. And in theory that's

622
00:34:29.719 --> 00:34:32.039
<v Speaker 3>true if you have saved all of the events, you

623
00:34:32.119 --> 00:34:36.960
<v Speaker 3>can basically generate new insights, new features, even based on

624
00:34:37.039 --> 00:34:39.119
<v Speaker 3>events that have happened in the past, and you can

625
00:34:39.239 --> 00:34:42.719
<v Speaker 3>repopulate the view by just letting that projection run until

626
00:34:42.760 --> 00:34:47.679
<v Speaker 3>it's caughta In practice, like often when you're extending a

627
00:34:47.719 --> 00:34:51.079
<v Speaker 3>feature set of an application, you're also introducing new events

628
00:34:51.480 --> 00:34:56.440
<v Speaker 3>and you will not taken those into account in the past,

629
00:34:56.559 --> 00:35:01.760
<v Speaker 3>so it that that claim has a limited validity. In practice,

630
00:35:03.000 --> 00:35:04.480
<v Speaker 3>but it's a cool selling point, right.

631
00:35:04.599 --> 00:35:07.480
<v Speaker 1>Yeah. So you've been talking about some of the problems

632
00:35:07.559 --> 00:35:11.679
<v Speaker 1>that have event sourcing solves. Are there any new challenges

633
00:35:11.760 --> 00:35:15.559
<v Speaker 1>with event sourcing that come into plug.

634
00:35:15.440 --> 00:35:21.840
<v Speaker 3>Oh, definitely, some of some of the challenges that, weirdly,

635
00:35:21.960 --> 00:35:25.280
<v Speaker 3>you don't have with a normalized database because if you

636
00:35:26.119 --> 00:35:31.599
<v Speaker 3>normalize your database properly, every bit of information is one

637
00:35:32.360 --> 00:35:34.480
<v Speaker 3>linked to the primary key of the table that it's in,

638
00:35:35.039 --> 00:35:38.840
<v Speaker 3>and it's only stored in one bit. So if you

639
00:35:38.880 --> 00:35:41.159
<v Speaker 3>do it right, you should end up with a pretty

640
00:35:41.639 --> 00:35:45.079
<v Speaker 3>deterministic view of what your data looks like and the

641
00:35:45.159 --> 00:35:47.320
<v Speaker 3>way that you query it and update it on whatever.

642
00:35:47.480 --> 00:35:47.519
<v Speaker 2>Like.

643
00:35:47.599 --> 00:35:50.000
<v Speaker 3>All of that is coding that happens afterward, so you

644
00:35:50.119 --> 00:35:54.519
<v Speaker 3>don't have to think about that too much. As soon

645
00:35:54.599 --> 00:35:59.840
<v Speaker 3>as you start applying event sourcing, partitioning your system based

646
00:36:00.119 --> 00:36:03.079
<v Speaker 3>on the root entity that the commands are going to

647
00:36:03.119 --> 00:36:07.559
<v Speaker 3>happen in basically determining the boundaries of your aggregates, that

648
00:36:07.760 --> 00:36:11.119
<v Speaker 3>becomes very important. But it's a problem that you also

649
00:36:11.320 --> 00:36:15.440
<v Speaker 3>see when you use a document database. For instance, if

650
00:36:15.480 --> 00:36:20.519
<v Speaker 3>you switched over to something like the dB or AVNDB

651
00:36:20.679 --> 00:36:23.519
<v Speaker 3>or whatever, you're going to see the same problem because

652
00:36:23.559 --> 00:36:26.079
<v Speaker 3>you have to really think about which bit of my

653
00:36:26.239 --> 00:36:31.360
<v Speaker 3>data belongs together and is a sensible scope to process commands.

654
00:36:31.480 --> 00:36:33.559
<v Speaker 3>Because as soon as you have to start working with

655
00:36:33.679 --> 00:36:36.599
<v Speaker 3>multiple documents and multiple streams at the same time, that's

656
00:36:36.679 --> 00:36:39.000
<v Speaker 3>when things get tricky, right, But.

657
00:36:39.119 --> 00:36:41.920
<v Speaker 1>Generally you know what those things are, right, I mean,

658
00:36:42.039 --> 00:36:45.000
<v Speaker 1>you generally have to find the tip of the iceberg

659
00:36:45.719 --> 00:36:48.440
<v Speaker 1>and then you know all the related data goes in

660
00:36:48.519 --> 00:36:52.480
<v Speaker 1>there as well. So isn't that's something that you would

661
00:36:52.519 --> 00:36:55.000
<v Speaker 1>probably know if you're familiar with the data shape.

662
00:36:55.119 --> 00:37:00.519
<v Speaker 3>If you're familiar with the data shape, yes, But fromans,

663
00:37:01.079 --> 00:37:06.199
<v Speaker 3>I feel like most developers that come from the crut

664
00:37:07.199 --> 00:37:12.599
<v Speaker 3>normalized database world they don't think that way and they've

665
00:37:12.679 --> 00:37:15.480
<v Speaker 3>never actually wondered like, which are my root entities?

666
00:37:15.760 --> 00:37:17.360
<v Speaker 2>Where does the stuff happen?

667
00:37:18.159 --> 00:37:22.960
<v Speaker 3>And as soon as you start mapping out business processes

668
00:37:23.840 --> 00:37:26.320
<v Speaker 3>and you start thinking about what is happening here in

669
00:37:26.440 --> 00:37:29.639
<v Speaker 3>my business? When does a user or an external system

670
00:37:29.760 --> 00:37:32.840
<v Speaker 3>q a command? What is happening when that command? Which

671
00:37:33.039 --> 00:37:35.920
<v Speaker 3>entity does that command hit? That's when all of that

672
00:37:36.119 --> 00:37:40.000
<v Speaker 3>becomes very clear. So if you practice things like domain

673
00:37:40.079 --> 00:37:43.719
<v Speaker 3>driven design and you start using things like even storming

674
00:37:43.880 --> 00:37:47.280
<v Speaker 3>to map out your business processes. With post its on

675
00:37:47.360 --> 00:37:51.320
<v Speaker 3>a wall, you end up with not only a very

676
00:37:51.400 --> 00:37:54.519
<v Speaker 3>clear view of how you're going to partition that system,

677
00:37:54.639 --> 00:37:56.840
<v Speaker 3>but you end up with post its that you can

678
00:37:57.079 --> 00:38:00.760
<v Speaker 3>one on one basically convert into class in code, because

679
00:38:00.800 --> 00:38:02.960
<v Speaker 3>those will become your commands and your events and all

680
00:38:03.000 --> 00:38:06.039
<v Speaker 3>of that. And of course there's there's work to do,

681
00:38:07.039 --> 00:38:07.519
<v Speaker 3>but at.

682
00:38:07.480 --> 00:38:09.199
<v Speaker 2>Least the the.

683
00:38:11.239 --> 00:38:15.000
<v Speaker 3>Amount of information that can get lost when you try

684
00:38:15.079 --> 00:38:18.519
<v Speaker 3>to translate that from that wideboard full of post its

685
00:38:18.559 --> 00:38:21.599
<v Speaker 3>into code is a lot closer than it would be

686
00:38:21.760 --> 00:38:25.000
<v Speaker 3>if you're using a relational database. It also will have

687
00:38:25.360 --> 00:38:26.760
<v Speaker 3>way less side effects.

688
00:38:27.000 --> 00:38:29.239
<v Speaker 1>So if you have if you create your what you

689
00:38:29.360 --> 00:38:33.199
<v Speaker 1>think is your hierarchy and your your your shape and

690
00:38:33.280 --> 00:38:37.239
<v Speaker 1>your root unit down and you start saving some events

691
00:38:37.280 --> 00:38:39.679
<v Speaker 1>and all that stuff, and then you realize, oh, I

692
00:38:39.800 --> 00:38:44.559
<v Speaker 1>need this entity in here as well. Does that change

693
00:38:44.599 --> 00:38:47.599
<v Speaker 1>anything or do those past events become invalid or in

694
00:38:47.679 --> 00:38:49.920
<v Speaker 1>the new event you've just added this entity.

695
00:38:50.440 --> 00:38:56.480
<v Speaker 3>And not really like there are definitely scenarios where you

696
00:38:56.599 --> 00:39:02.360
<v Speaker 3>are going to touch multiple multiple streams as a result

697
00:39:02.440 --> 00:39:05.440
<v Speaker 3>of a single command. Think about your shopping car, for instance,

698
00:39:05.480 --> 00:39:07.960
<v Speaker 3>at some point you're also going to touch the stock system,

699
00:39:09.039 --> 00:39:12.199
<v Speaker 3>so that might be another stream that lives in the

700
00:39:12.280 --> 00:39:17.159
<v Speaker 3>same application. That might be an external system that needs

701
00:39:17.199 --> 00:39:18.920
<v Speaker 3>to get called, right, so.

702
00:39:19.000 --> 00:39:21.440
<v Speaker 1>You're not trying to make one stream that rules them all.

703
00:39:22.559 --> 00:39:25.880
<v Speaker 1>This is what you're talking about boundaries having where do

704
00:39:25.920 --> 00:39:28.119
<v Speaker 1>you separate those things exactly?

705
00:39:28.199 --> 00:39:30.840
<v Speaker 3>And you have to figure out where the boundaries are

706
00:39:31.079 --> 00:39:35.880
<v Speaker 3>and cross them with a very conscious state of mind.

707
00:39:35.960 --> 00:39:39.639
<v Speaker 3>I have to worry about where am I leaving, like

708
00:39:39.760 --> 00:39:41.519
<v Speaker 3>the thing that I can do on a single stream,

709
00:39:42.360 --> 00:39:45.000
<v Speaker 3>and there has to be a very good reason for that. Like,

710
00:39:45.119 --> 00:39:47.880
<v Speaker 3>if all of your commands are doing that, then you

711
00:39:48.079 --> 00:39:49.480
<v Speaker 3>model something really wrong.

712
00:39:50.679 --> 00:39:53.079
<v Speaker 2>Yeah, I think single stream for everything is bad too,

713
00:39:53.199 --> 00:39:55.039
<v Speaker 2>but I'm sure you end up with arguments about too

714
00:39:55.079 --> 00:39:55.719
<v Speaker 2>many streams.

715
00:39:56.679 --> 00:40:00.199
<v Speaker 3>So the like, there's a couple of patterns that you

716
00:40:00.280 --> 00:40:03.239
<v Speaker 3>can use. For instance, like the saga pattern is very

717
00:40:03.320 --> 00:40:06.920
<v Speaker 3>well known. If you have a command that comes into

718
00:40:06.960 --> 00:40:09.920
<v Speaker 3>your system that's going to touch multiple streams or even

719
00:40:10.000 --> 00:40:12.800
<v Speaker 3>multiple systems if you have to make external calls, what

720
00:40:12.960 --> 00:40:17.920
<v Speaker 3>you typically have is a quite long running transaction that

721
00:40:18.079 --> 00:40:20.960
<v Speaker 3>is going to be happening as soon as that command

722
00:40:21.039 --> 00:40:24.480
<v Speaker 3>comes in, right, So you're going to save some intermediary

723
00:40:24.559 --> 00:40:28.320
<v Speaker 3>states and let the whole thing play out because with

724
00:40:28.480 --> 00:40:31.320
<v Speaker 3>external systems, it might be an outgoing call and then

725
00:40:31.360 --> 00:40:33.280
<v Speaker 3>a callback coming in and whatever you're going to have

726
00:40:33.360 --> 00:40:35.280
<v Speaker 3>to be able to pick up the threat. That's a

727
00:40:35.360 --> 00:40:39.840
<v Speaker 3>perfect way to model that, and it's not that dissimilar

728
00:40:40.000 --> 00:40:44.280
<v Speaker 3>from how you model more complex transactions across multiple streams

729
00:40:45.000 --> 00:40:50.679
<v Speaker 3>and inside the system. Now if you use frameworks, because

730
00:40:50.719 --> 00:40:53.559
<v Speaker 3>a lot of it depends on what is backing your

731
00:40:55.559 --> 00:40:58.119
<v Speaker 3>what is backing your event sourcing framework, Like you can

732
00:40:58.239 --> 00:41:00.079
<v Speaker 3>roll your own. A lot of it is not that

733
00:41:00.239 --> 00:41:04.519
<v Speaker 3>complex and you needed probably about a day to to

734
00:41:05.039 --> 00:41:10.239
<v Speaker 3>roll something that can do a lot of the things

735
00:41:10.760 --> 00:41:12.840
<v Speaker 3>if you want to have something battle tested and let

736
00:41:12.920 --> 00:41:15.519
<v Speaker 3>somebody else think about hard work. You've had Jeremy on

737
00:41:15.599 --> 00:41:19.960
<v Speaker 3>the show and we talked about Martin his Martin framework

738
00:41:20.280 --> 00:41:23.960
<v Speaker 3>is well, it's not is it a framework or a

739
00:41:24.039 --> 00:41:27.800
<v Speaker 3>document database? It's an event store right right? What Martin

740
00:41:28.079 --> 00:41:31.320
<v Speaker 3>calls it a web framework. Yeah, well that's that's if

741
00:41:31.360 --> 00:41:34.320
<v Speaker 3>you involve Wolverine and and and all the other things

742
00:41:34.360 --> 00:41:41.079
<v Speaker 3>of the Critter, Critter Stack, the creator. But Martin Martin

743
00:41:41.199 --> 00:41:45.639
<v Speaker 3>is basically I don't know if that's my story to tell.

744
00:41:45.800 --> 00:41:47.719
<v Speaker 3>I'm sure Jeremy told it on the show.

745
00:41:47.519 --> 00:41:49.400
<v Speaker 2>As well, Like he's been on a few times.

746
00:41:49.800 --> 00:41:52.679
<v Speaker 3>They they ran into trouble with with raven dB, if

747
00:41:52.719 --> 00:41:55.880
<v Speaker 3>I remember correctly, and they needed something capable of handling

748
00:41:55.920 --> 00:41:58.039
<v Speaker 3>the load, and they looked at postcrests. It's like, cool,

749
00:41:58.079 --> 00:41:59.920
<v Speaker 3>Postcrest can do a lot of stuff that we need

750
00:42:00.039 --> 00:42:03.079
<v Speaker 3>when it comes to the document stuff, but the projection

751
00:42:03.199 --> 00:42:06.400
<v Speaker 3>stuff that's in raven like not so much. And that's

752
00:42:06.440 --> 00:42:09.960
<v Speaker 3>why they ended up building a lot of what Martin

753
00:42:10.199 --> 00:42:13.519
<v Speaker 3>eventually became. And because that had documents in there and

754
00:42:13.639 --> 00:42:17.400
<v Speaker 3>had projections in there like, it became a very nice

755
00:42:17.519 --> 00:42:21.719
<v Speaker 3>candidate for building an event source system as well, because

756
00:42:21.760 --> 00:42:25.159
<v Speaker 3>if you have a stream with all your documents that

757
00:42:25.519 --> 00:42:27.840
<v Speaker 3>have all of your events that have happened in the past,

758
00:42:28.719 --> 00:42:31.760
<v Speaker 3>and you can run projections on that, then you're already

759
00:42:32.079 --> 00:42:34.159
<v Speaker 3>like eighty percent of the way there to have an

760
00:42:34.199 --> 00:42:37.519
<v Speaker 3>event source system where you have your event stream and

761
00:42:37.599 --> 00:42:40.199
<v Speaker 3>you have your projections that project into other documents or

762
00:42:40.239 --> 00:42:44.079
<v Speaker 3>other tables or whatever, which is why Martin now has

763
00:42:44.079 --> 00:42:48.800
<v Speaker 3>a very explicit support for event sourcing, and you get

764
00:42:48.840 --> 00:42:50.760
<v Speaker 3>an out of the box event stream that you can

765
00:42:51.000 --> 00:42:54.239
<v Speaker 3>pentax to and it supports all the things that you

766
00:42:54.400 --> 00:42:59.360
<v Speaker 3>will run run into at first when you start growing

767
00:42:59.480 --> 00:43:01.960
<v Speaker 3>one of these systems, because one of the typical problems

768
00:43:02.039 --> 00:43:05.159
<v Speaker 3>is you have a certain aggregate that becomes very long

769
00:43:05.239 --> 00:43:08.880
<v Speaker 3>lived and it starts accumulating not thousands, but millions of

770
00:43:08.960 --> 00:43:13.039
<v Speaker 3>events that becomes very expensive to replay. So at some

771
00:43:13.159 --> 00:43:15.599
<v Speaker 3>point you're going to want to start snapshotting that. Right,

772
00:43:15.719 --> 00:43:18.679
<v Speaker 3>We're going to take a snapshot at events one million,

773
00:43:18.840 --> 00:43:20.920
<v Speaker 3>two hundred and sixty four so that we only have

774
00:43:21.039 --> 00:43:26.559
<v Speaker 3>to replay the last fifty, right, and all of that

775
00:43:26.760 --> 00:43:31.599
<v Speaker 3>functionality is already built in. Somebody has thought about that way,

776
00:43:31.960 --> 00:43:34.880
<v Speaker 3>about those things way harder than most of us ever will,

777
00:43:35.639 --> 00:43:38.960
<v Speaker 3>And I think that's a very valid argument to start

778
00:43:39.159 --> 00:43:43.440
<v Speaker 3>using one of those ready made frameworks to do that

779
00:43:43.800 --> 00:43:46.159
<v Speaker 3>kind of stuff. But you do have to understand what

780
00:43:46.400 --> 00:43:50.000
<v Speaker 3>goes on behind the scenes, because if you register a

781
00:43:50.079 --> 00:43:54.760
<v Speaker 3>projection in there, that's going to spin off a background

782
00:43:54.880 --> 00:43:57.639
<v Speaker 3>worker that's actually going to be querrying your database and

783
00:43:57.760 --> 00:44:00.639
<v Speaker 3>running code and writing back to the database. So none

784
00:44:00.679 --> 00:44:03.480
<v Speaker 3>of that's it happens magically, but it's not.

785
00:44:03.599 --> 00:44:05.599
<v Speaker 2>Free, right. Yeah. I was just going back and look

786
00:44:05.639 --> 00:44:07.559
<v Speaker 2>at the Jerry Miller shows and realized the entire thing

787
00:44:07.639 --> 00:44:09.960
<v Speaker 2>that you've just told we've done as a series of

788
00:44:10.000 --> 00:44:13.440
<v Speaker 2>shows with him about Martin on Postgrass, then playing with

789
00:44:13.559 --> 00:44:18.920
<v Speaker 2>events sourcing, and then Wolverine, and it's literally working through

790
00:44:19.000 --> 00:44:22.199
<v Speaker 2>the problems you're describing as this works up to this

791
00:44:22.320 --> 00:44:23.960
<v Speaker 2>point and then you need to go over here and

792
00:44:24.159 --> 00:44:25.320
<v Speaker 2>like it's just it's.

793
00:44:25.320 --> 00:44:28.400
<v Speaker 3>Yeah, Wolverine is very nice SAGA support, right, So if

794
00:44:28.440 --> 00:44:30.800
<v Speaker 3>you pair that with Martin, that works really well.

795
00:44:30.920 --> 00:44:35.519
<v Speaker 2>Now we're back in the critter stack exactly. There's a

796
00:44:35.599 --> 00:44:37.519
<v Speaker 2>reason that we have all these different critters.

797
00:44:37.800 --> 00:44:40.400
<v Speaker 3>Yeah, But like I think at this moment in the

798
00:44:40.480 --> 00:44:44.320
<v Speaker 3>dot net space, Martin is probably one of the one

799
00:44:44.360 --> 00:44:47.159
<v Speaker 3>of the best ways to get started with events sourcing

800
00:44:47.639 --> 00:44:49.679
<v Speaker 3>because you get a lot of stuff out of the

801
00:44:49.760 --> 00:44:54.079
<v Speaker 3>box and the complexity of the setup for you as

802
00:44:54.239 --> 00:45:00.239
<v Speaker 3>the person developing the system, the complexity is relative fully

803
00:45:00.320 --> 00:45:02.639
<v Speaker 3>low because what you need is a dot net process

804
00:45:02.800 --> 00:45:05.960
<v Speaker 3>that connects to a postcress database, right, and if you

805
00:45:06.079 --> 00:45:10.840
<v Speaker 3>have multiple nodes doing that, they will actually communicate through

806
00:45:11.440 --> 00:45:15.360
<v Speaker 3>postcress locks, so you don't need anything out of band

807
00:45:16.159 --> 00:45:19.559
<v Speaker 3>for your notes to make sure that they're not interfering

808
00:45:19.639 --> 00:45:20.320
<v Speaker 3>with one another.

809
00:45:20.519 --> 00:45:23.119
<v Speaker 2>What makes postcrests special in this situation, Like I I

810
00:45:23.119 --> 00:45:25.840
<v Speaker 2>already have SQL server why wouldn't I use it basin

811
00:45:26.400 --> 00:45:28.599
<v Speaker 2>binary chasin binary Jason.

812
00:45:28.360 --> 00:45:33.239
<v Speaker 1>Okay, no, well SQL server has adjacent table field type now, yeah,

813
00:45:33.679 --> 00:45:34.559
<v Speaker 1>but it's more expensive.

814
00:45:34.679 --> 00:45:38.519
<v Speaker 3>Yeah, but for a long time they didn't. And postcress

815
00:45:38.599 --> 00:45:42.000
<v Speaker 3>is is still a lot more powerful than what the

816
00:45:42.360 --> 00:45:43.199
<v Speaker 3>server is trying.

817
00:45:43.360 --> 00:45:46.079
<v Speaker 2>I also like the licensing on postgrass, which is to

818
00:45:46.239 --> 00:45:49.960
<v Speaker 2>say free. Yeah, but.

819
00:45:51.840 --> 00:45:56.199
<v Speaker 3>Postcress is ridiculously powerful and it does a lot of

820
00:45:56.360 --> 00:46:00.480
<v Speaker 3>things very well. And Basin is basically a way that

821
00:46:00.679 --> 00:46:04.159
<v Speaker 3>they figured out to store chasing documents in a binary

822
00:46:04.280 --> 00:46:07.599
<v Speaker 3>format in a way that they could still index on

823
00:46:08.400 --> 00:46:15.400
<v Speaker 3>fields that are pretty deep in the document's tree, which

824
00:46:15.480 --> 00:46:21.000
<v Speaker 3>is cool. Added benefit is this works in an acid

825
00:46:21.320 --> 00:46:26.480
<v Speaker 3>transactional database, which Mongo. In Mongo, for instance, you have

826
00:46:28.320 --> 00:46:32.800
<v Speaker 3>transactions on document level, but not across multiple documents. And

827
00:46:32.960 --> 00:46:36.480
<v Speaker 3>with postgress, that's a thing that's there by default because

828
00:46:37.360 --> 00:46:40.880
<v Speaker 3>by default it's an ASTE compliant relational database. And because

829
00:46:41.360 --> 00:46:44.320
<v Speaker 3>basin is so powerful, like in a lot of scenarios,

830
00:46:44.960 --> 00:46:48.760
<v Speaker 3>it will outperform a lot of other document databases while

831
00:46:49.519 --> 00:46:54.159
<v Speaker 3>basically being a relational database. And I get the irony, like,

832
00:46:54.320 --> 00:46:56.800
<v Speaker 3>now we're going to use a relational database to store

833
00:46:56.880 --> 00:46:58.599
<v Speaker 3>our events stream and our documents.

834
00:46:59.360 --> 00:47:01.079
<v Speaker 1>But you know, but at the same time you get

835
00:47:01.159 --> 00:47:03.000
<v Speaker 1>the relational stuff you need that too, So.

836
00:47:03.320 --> 00:47:05.760
<v Speaker 3>Yes, and and that's one of the cool things. If

837
00:47:05.800 --> 00:47:09.639
<v Speaker 3>you want to project your events into actual sequel tables,

838
00:47:09.840 --> 00:47:13.920
<v Speaker 3>like you can do that in the same transactions. You

839
00:47:14.000 --> 00:47:17.679
<v Speaker 3>will be able to run if you want. You can

840
00:47:17.800 --> 00:47:21.239
<v Speaker 3>have some of your projections transactionally consistent, meaning that they

841
00:47:21.280 --> 00:47:24.760
<v Speaker 3>will project when you're saving the event. Like that's the

842
00:47:24.920 --> 00:47:30.159
<v Speaker 3>hard stuff, like figuring figuring all of that out in

843
00:47:30.559 --> 00:47:32.679
<v Speaker 3>a framework that you're going to roll yourself is going

844
00:47:32.760 --> 00:47:36.920
<v Speaker 3>to cost so much time. And that's when Martin, for instance,

845
00:47:37.079 --> 00:47:38.719
<v Speaker 3>shines because it has.

846
00:47:38.639 --> 00:47:39.440
<v Speaker 2>All that building.

847
00:47:40.199 --> 00:47:43.199
<v Speaker 3>But Basin is a lot of the reason why that

848
00:47:43.480 --> 00:47:46.039
<v Speaker 3>works with postgress.

849
00:47:46.159 --> 00:47:51.159
<v Speaker 1>Do you think agentic coding with LLLMS is going to

850
00:47:52.159 --> 00:47:57.039
<v Speaker 1>help or hurt the efforts of events sourcing?

851
00:47:57.400 --> 00:48:01.119
<v Speaker 3>I think, But of course i'm comfort in this. I

852
00:48:01.239 --> 00:48:07.280
<v Speaker 3>might be prejudiced because a lot of the patterns that

853
00:48:07.519 --> 00:48:13.400
<v Speaker 3>come from using event sourcing they're relatively side effect free.

854
00:48:14.360 --> 00:48:16.679
<v Speaker 3>Like your projection is going to touch the table that

855
00:48:16.760 --> 00:48:19.199
<v Speaker 3>it's updating, but it's not going to touch anything else.

856
00:48:19.360 --> 00:48:21.480
<v Speaker 3>It reads from the statement writes to a single table,

857
00:48:22.159 --> 00:48:24.559
<v Speaker 3>and the same with your commands, like you're fetching a

858
00:48:24.599 --> 00:48:26.800
<v Speaker 3>bunch of events and then you're appending to the stream.

859
00:48:26.880 --> 00:48:30.679
<v Speaker 3>You're not updating records, you're not walking records. Like a

860
00:48:30.760 --> 00:48:34.320
<v Speaker 3>lot of that is actually easy to performance tune down

861
00:48:34.360 --> 00:48:39.280
<v Speaker 3>the line because that code is relatively side effect free.

862
00:48:40.519 --> 00:48:44.280
<v Speaker 3>The patterns that are used in event sourcing would actually

863
00:48:44.519 --> 00:48:52.000
<v Speaker 3>be very very adequate for generating code, because if you're

864
00:48:52.079 --> 00:48:54.440
<v Speaker 3>trying to explain to an agent like, hey, this is

865
00:48:54.480 --> 00:48:57.039
<v Speaker 3>what my business process looks like, these are the commands,

866
00:48:57.079 --> 00:48:59.719
<v Speaker 3>and then this happens. Basically the way that we think

867
00:49:00.039 --> 00:49:04.719
<v Speaker 3>out the world, right, if we figure out our drink

868
00:49:04.920 --> 00:49:07.960
<v Speaker 3>order at the bar, it's a conversation, it goes back

869
00:49:08.039 --> 00:49:11.480
<v Speaker 3>and forth, and it's the way our world works, is

870
00:49:11.519 --> 00:49:15.320
<v Speaker 3>the way that software systems work, and especially event source systems.

871
00:49:15.760 --> 00:49:18.000
<v Speaker 3>And I think that because there is less of a

872
00:49:18.079 --> 00:49:22.480
<v Speaker 3>translation happening between the business problem and the actual code,

873
00:49:22.840 --> 00:49:27.000
<v Speaker 3>I think this will actually lend itself very well to

874
00:49:28.639 --> 00:49:32.920
<v Speaker 3>getting generated systems from from agents or whatever. Of course,

875
00:49:32.960 --> 00:49:35.719
<v Speaker 3>we don't have to train them on code basis that

876
00:49:36.159 --> 00:49:39.760
<v Speaker 3>deal with normalize databases, but that's not a hard problem

877
00:49:39.840 --> 00:49:42.719
<v Speaker 3>to solve, right if you're training LLLMS.

878
00:49:43.159 --> 00:49:44.599
<v Speaker 2>I haven't done any of this testing yet, but it

879
00:49:44.639 --> 00:49:47.679
<v Speaker 2>makes a lot of sense to see could we point

880
00:49:47.800 --> 00:49:52.039
<v Speaker 2>an LLM at an existing SQRES implementation, say, is this

881
00:49:52.119 --> 00:49:57.920
<v Speaker 2>a well implemented event source pattern application? You know, because

882
00:49:58.119 --> 00:49:59.400
<v Speaker 2>the first thing I want to do is be able

883
00:49:59.400 --> 00:50:01.480
<v Speaker 2>to test. Is they already doing this right before I

884
00:50:01.639 --> 00:50:04.559
<v Speaker 2>even ask you to generate any code? Sure? Yeah, I've

885
00:50:04.599 --> 00:50:07.199
<v Speaker 2>not tried, no, but this is an interesting idea to say,

886
00:50:07.679 --> 00:50:11.000
<v Speaker 2>could these tools be really effective at this pattern based

887
00:50:11.039 --> 00:50:12.599
<v Speaker 2>development approach? Yeah?

888
00:50:12.920 --> 00:50:17.199
<v Speaker 3>Curious est part of the reason that this is gaining

889
00:50:17.239 --> 00:50:20.639
<v Speaker 3>a lot of traction in the DDD world is because

890
00:50:20.719 --> 00:50:25.960
<v Speaker 3>of the lack of translation from the business concepts to

891
00:50:26.159 --> 00:50:29.440
<v Speaker 3>the actual classes that you're going to see for your events.

892
00:50:29.800 --> 00:50:31.559
<v Speaker 2>I like the attitude, and I thought I've said this

893
00:50:31.599 --> 00:50:34.199
<v Speaker 2>before on the show of Just Store the truth. Order

894
00:50:34.280 --> 00:50:36.440
<v Speaker 2>comes in store the order. What you do with it

895
00:50:36.519 --> 00:50:38.760
<v Speaker 2>after that is secondary the point. But the fact that

896
00:50:38.840 --> 00:50:42.840
<v Speaker 2>you have a record of what happened, a complete as

897
00:50:42.920 --> 00:50:45.519
<v Speaker 2>it was at the moment. I think it's really powerful.

898
00:50:45.599 --> 00:50:48.440
<v Speaker 2>And the only price there is disk space, and this

899
00:50:48.559 --> 00:50:49.519
<v Speaker 2>space is trivial.

900
00:50:49.639 --> 00:50:53.599
<v Speaker 3>It's cheap, especially if it's structured data like chasing documents.

901
00:50:54.119 --> 00:50:56.840
<v Speaker 1>Yeah, it's very easy, and I imagine the base on

902
00:50:57.400 --> 00:51:01.679
<v Speaker 1>data takes up way less dispace. Then oh yeah, ASKI

903
00:51:02.320 --> 00:51:03.840
<v Speaker 1>chasonski chasing.

904
00:51:03.920 --> 00:51:05.719
<v Speaker 3>But even asky chasin isn't that bad.

905
00:51:05.920 --> 00:51:09.639
<v Speaker 2>It's not yah, and this base is not the issue.

906
00:51:09.719 --> 00:51:11.719
<v Speaker 2>I mean parsing all that after the fact, you can

907
00:51:11.840 --> 00:51:14.960
<v Speaker 2>you can discuss from there, But first and foremost, it's

908
00:51:15.039 --> 00:51:16.880
<v Speaker 2>just a good idea to keep a record of the truth.

909
00:51:17.360 --> 00:51:20.199
<v Speaker 3>You know, you can don't be mistaken like you're not

910
00:51:20.440 --> 00:51:25.320
<v Speaker 3>getting auditing information like out of the box, because that's

911
00:51:25.320 --> 00:51:29.280
<v Speaker 3>a common misconception about events sourcing. If you want to

912
00:51:29.400 --> 00:51:32.760
<v Speaker 3>have your full audit trail of what happened for legal

913
00:51:32.840 --> 00:51:36.119
<v Speaker 3>reasons or whatever, you're gonna need to enrich that data

914
00:51:36.199 --> 00:51:40.480
<v Speaker 3>a little bit because who is important, Like who made

915
00:51:40.639 --> 00:51:42.920
<v Speaker 3>the command that came in? What was the command that

916
00:51:43.079 --> 00:51:46.719
<v Speaker 3>came in, what events resulted from that, what changes it

917
00:51:46.800 --> 00:51:50.239
<v Speaker 3>a like due to the entity? Like the last part

918
00:51:50.320 --> 00:51:52.639
<v Speaker 3>is what you're getting for free with your event stream,

919
00:51:52.840 --> 00:51:55.199
<v Speaker 3>but you need to also lock your commands and add

920
00:51:55.280 --> 00:51:58.679
<v Speaker 3>some metadata like who did this and when did they do?

921
00:51:58.880 --> 00:52:01.039
<v Speaker 2>Is the only thing you're getting for sure is the results,

922
00:52:01.360 --> 00:52:04.239
<v Speaker 2>But to keep the detail of how you got to

923
00:52:04.360 --> 00:52:07.480
<v Speaker 2>this result, that's up to you exactly where does this struggle?

924
00:52:07.719 --> 00:52:10.039
<v Speaker 2>Like where do where do you get to? Where does

925
00:52:10.079 --> 00:52:10.840
<v Speaker 2>this get into trouble?

926
00:52:11.000 --> 00:52:13.960
<v Speaker 3>Oh like GDPR becomes tricky?

927
00:52:14.559 --> 00:52:20.800
<v Speaker 2>Oh yeah, oh interesting, mostly protecting privably identifiable information.

928
00:52:21.079 --> 00:52:25.599
<v Speaker 3>Yeah, because you you in a way, you want to

929
00:52:25.719 --> 00:52:28.320
<v Speaker 3>have everything that happened in your system in your in

930
00:52:28.440 --> 00:52:31.639
<v Speaker 3>your streams. And it's very easy, like if Carl asks

931
00:52:31.800 --> 00:52:35.280
<v Speaker 3>to have his information deleted, like we're is going to

932
00:52:35.360 --> 00:52:41.360
<v Speaker 3>delete his streams from our events stream, but that might

933
00:52:41.440 --> 00:52:43.960
<v Speaker 3>affect the next time that I'm running.

934
00:52:46.639 --> 00:52:49.679
<v Speaker 2>Check the stuff out. Yeah, well, and he's not. He's

935
00:52:49.679 --> 00:52:51.800
<v Speaker 2>not asking to delete the sales record. The sales record

936
00:52:51.920 --> 00:52:56.000
<v Speaker 2>is the truth. It's the identifiable information. They identifiable information.

937
00:52:56.119 --> 00:52:59.679
<v Speaker 2>And then you come into situations where there's certain information

938
00:52:59.840 --> 00:53:02.480
<v Speaker 2>like passwords for instance, you're not gonna want in your

939
00:53:02.519 --> 00:53:06.119
<v Speaker 2>events stream, but they still need to go somewhere, right, Yeah,

940
00:53:06.599 --> 00:53:09.400
<v Speaker 2>so you're you might end up masking some data in

941
00:53:09.440 --> 00:53:13.880
<v Speaker 2>the event stream that you're gonna store somewhere else or

942
00:53:14.199 --> 00:53:17.199
<v Speaker 2>deal with elsewhere. Right. I don't know if it's compliant,

943
00:53:17.239 --> 00:53:19.679
<v Speaker 2>but my instinct there is I never modify the stream,

944
00:53:20.159 --> 00:53:22.360
<v Speaker 2>but I do flag we don't have access to this

945
00:53:22.440 --> 00:53:23.239
<v Speaker 2>person's information.

946
00:53:23.320 --> 00:53:26.440
<v Speaker 1>Anymore, so you never show it. Well, but is that

947
00:53:26.559 --> 00:53:28.480
<v Speaker 1>the same as deleting it in in in.

948
00:53:30.039 --> 00:53:35.320
<v Speaker 3>Like I think the GDPR legislation forces you can actually

949
00:53:35.480 --> 00:53:38.320
<v Speaker 3>delete ith right, you can no longer have it on file.

950
00:53:38.400 --> 00:53:40.159
<v Speaker 2>That's what I thought too. Yeah, so do you have

951
00:53:40.280 --> 00:53:42.679
<v Speaker 2>to go back through all of your historical records that

952
00:53:42.719 --> 00:53:46.039
<v Speaker 2>were burned a DVD and delete those two? That's I

953
00:53:46.159 --> 00:53:49.000
<v Speaker 2>love compliance. Compliance is the best, but that's that's.

954
00:53:48.920 --> 00:53:53.119
<v Speaker 3>One of those problems where events sourcing gets tricky.

955
00:53:53.440 --> 00:53:57.480
<v Speaker 2>For instance, Yeah, this idea of keeping a record of

956
00:53:57.519 --> 00:53:58.079
<v Speaker 2>the truth.

957
00:53:57.960 --> 00:54:01.239
<v Speaker 3>Now to be honest, like any any system here, if

958
00:54:01.280 --> 00:54:02.599
<v Speaker 3>you start thinking about.

959
00:54:02.400 --> 00:54:05.320
<v Speaker 2>That, Yeah, and my niceing innolational database is I can

960
00:54:05.400 --> 00:54:09.039
<v Speaker 2>this customer wants to be forgotten and so we erase

961
00:54:09.119 --> 00:54:11.800
<v Speaker 2>their identifal inform infusiation from the record? I think I

962
00:54:12.159 --> 00:54:16.400
<v Speaker 2>still keep the pointer record, like just the ID, but

963
00:54:16.519 --> 00:54:19.280
<v Speaker 2>none of their information. Isn't that ID anymore? And that

964
00:54:19.559 --> 00:54:20.360
<v Speaker 2>that also.

965
00:54:22.119 --> 00:54:26.960
<v Speaker 3>Begs the question like, okay, we still want to track

966
00:54:27.039 --> 00:54:31.239
<v Speaker 3>Carl as one of the people that registered for our website,

967
00:54:31.320 --> 00:54:33.760
<v Speaker 3>like how many users sign ups did we have? Right?

968
00:54:34.679 --> 00:54:37.760
<v Speaker 3>And if we drop his stream like that event might

969
00:54:37.840 --> 00:54:40.320
<v Speaker 3>be gone. So then you have to start thinking about Okay,

970
00:54:40.440 --> 00:54:45.000
<v Speaker 3>if we want to model that particular bit of information

971
00:54:45.159 --> 00:54:47.920
<v Speaker 3>like new users signed up, we're going to have to

972
00:54:48.000 --> 00:54:51.440
<v Speaker 3>have a user signed up event in another aggregate that

973
00:54:51.559 --> 00:54:55.880
<v Speaker 3>does not get deleted when Carl's stream is removed from

974
00:54:55.920 --> 00:54:59.039
<v Speaker 3>the system, so that that information is still still accurate.

975
00:54:59.199 --> 00:55:05.480
<v Speaker 3>Like those things becomes more intentional.

976
00:55:06.639 --> 00:55:09.280
<v Speaker 1>Do you leave the name and erase everything else or

977
00:55:09.360 --> 00:55:12.159
<v Speaker 1>replace it with not available or scrubbed or something like

978
00:55:12.239 --> 00:55:13.639
<v Speaker 1>redacted or something like that.

979
00:55:14.079 --> 00:55:17.400
<v Speaker 3>There's there's different different approaches that you can take. Yeah,

980
00:55:18.480 --> 00:55:22.079
<v Speaker 3>but very very most Margin for instance, allows you to

981
00:55:22.280 --> 00:55:27.719
<v Speaker 3>archive certain streams, which means that like this aggregate is

982
00:55:27.760 --> 00:55:29.239
<v Speaker 3>never going to get fetched back again.

983
00:55:29.400 --> 00:55:29.880
<v Speaker 2>And then.

984
00:55:31.719 --> 00:55:34.840
<v Speaker 3>In theory, you could just delete that from the database.

985
00:55:35.280 --> 00:55:39.000
<v Speaker 3>You could go through you could execute a simple command

986
00:55:39.039 --> 00:55:43.000
<v Speaker 3>saying like every every event where we have the archived

987
00:55:43.079 --> 00:55:46.239
<v Speaker 3>flag set to TROW, we can delete that. But then

988
00:55:46.280 --> 00:55:49.159
<v Speaker 3>you have to really worry about like, okay, which projections

989
00:55:49.599 --> 00:55:51.960
<v Speaker 3>might that affect and is that a bad thing? Is

990
00:55:52.000 --> 00:55:52.679
<v Speaker 3>that a problem?

991
00:55:52.760 --> 00:55:53.039
<v Speaker 2>Okay?

992
00:55:53.159 --> 00:55:57.039
<v Speaker 3>If this, and that's also a reason why you might

993
00:55:57.199 --> 00:56:00.320
<v Speaker 3>want to rebuild stuff, because I might delete the data

994
00:56:00.400 --> 00:56:03.920
<v Speaker 3>from the stream, I might delete defense, but the data

995
00:56:04.000 --> 00:56:08.960
<v Speaker 3>might still be in the projected in the projection tables.

996
00:56:09.719 --> 00:56:15.360
<v Speaker 3>So that's one of the reasons to periodically rerun or update,

997
00:56:15.719 --> 00:56:18.119
<v Speaker 3>like rebuild certain protections.

998
00:56:18.440 --> 00:56:20.880
<v Speaker 2>And you got to get I'm so low to the

999
00:56:21.000 --> 00:56:24.039
<v Speaker 2>leade data just because you know what you are, you

1000
00:56:24.119 --> 00:56:25.920
<v Speaker 2>sure you're deleting the right things, Like I can also

1001
00:56:25.960 --> 00:56:28.480
<v Speaker 2>get in trouble with the government for not reporting sales

1002
00:56:28.519 --> 00:56:31.599
<v Speaker 2>because I had to forget this person and forgot their sales.

1003
00:56:32.079 --> 00:56:34.280
<v Speaker 1>Yeah, well that's true. Got to keep it around at

1004
00:56:34.360 --> 00:56:35.760
<v Speaker 1>least until you pay the sales.

1005
00:56:35.559 --> 00:56:38.199
<v Speaker 2>Tax or whatever that. Yeah, and probably have to keep

1006
00:56:38.199 --> 00:56:40.159
<v Speaker 2>it around forever you can. You know, you get audited,

1007
00:56:40.480 --> 00:56:42.679
<v Speaker 2>you still have to make sure your sales are correct. Yeah,

1008
00:56:42.679 --> 00:56:44.920
<v Speaker 2>there's a in the United States, there's like a ten

1009
00:56:45.000 --> 00:56:47.840
<v Speaker 2>year window or something after which you can delete anything

1010
00:56:47.880 --> 00:56:50.000
<v Speaker 2>you want. Yeah, but even then you I mean, it's

1011
00:56:50.039 --> 00:56:51.960
<v Speaker 2>smart to keep track of all of your sales, who

1012
00:56:52.039 --> 00:56:54.960
<v Speaker 2>you sold it to. That's identifiable information. You can delete that,

1013
00:56:55.239 --> 00:56:58.239
<v Speaker 2>yeah yeah, yeah, yeah. I just suddenly have this vision

1014
00:56:58.280 --> 00:57:02.159
<v Speaker 2>of you have these streams marked GDPR redacted user yeah

1015
00:57:02.320 --> 00:57:05.320
<v Speaker 2>number you know eleven, that kind of thing.

1016
00:57:06.280 --> 00:57:11.480
<v Speaker 3>If certain events, for instance, contain identifiable information, you can

1017
00:57:11.719 --> 00:57:13.719
<v Speaker 3>mask that. You can say, like this field and that

1018
00:57:13.960 --> 00:57:17.559
<v Speaker 3>type of event. I don't want it to be safe

1019
00:57:17.599 --> 00:57:18.119
<v Speaker 3>to the stream.

1020
00:57:18.440 --> 00:57:21.679
<v Speaker 1>And then you just but if the federalies say you

1021
00:57:21.800 --> 00:57:23.360
<v Speaker 1>have to delete it, you have to delete it.

1022
00:57:23.519 --> 00:57:26.199
<v Speaker 2>Yeah, answers the question of what are you deleting, right

1023
00:57:26.559 --> 00:57:29.280
<v Speaker 2>because at the same time I have another federale saying

1024
00:57:29.599 --> 00:57:33.360
<v Speaker 2>you can't delete sales records. Yea, I will send you

1025
00:57:33.440 --> 00:57:34.559
<v Speaker 2>to prison for hiding income.

1026
00:57:34.880 --> 00:57:39.679
<v Speaker 3>Another thing that becomes tricky over time is versioning of events.

1027
00:57:40.480 --> 00:57:43.559
<v Speaker 3>Events may evolve over time and become.

1028
00:57:43.440 --> 00:57:46.719
<v Speaker 2>Sure new version of the sotom more elaborate or more

1029
00:57:46.840 --> 00:57:48.719
<v Speaker 2>complex or simpler.

1030
00:57:48.880 --> 00:57:52.119
<v Speaker 3>A certain command might certainly spawn two events instead of one.

1031
00:57:52.760 --> 00:57:57.719
<v Speaker 3>Suddenly you have as long as your objects are backwards

1032
00:57:57.760 --> 00:58:01.239
<v Speaker 3>compatible to whatever is saved in or data store, like,

1033
00:58:01.360 --> 00:58:03.880
<v Speaker 3>that's not a problem. But at some time you're going

1034
00:58:03.960 --> 00:58:04.400
<v Speaker 3>to break that.

1035
00:58:04.719 --> 00:58:09.280
<v Speaker 2>Yeah, you a replayable state somehow. And the easiest thing

1036
00:58:09.440 --> 00:58:10.079
<v Speaker 2>is is to.

1037
00:58:11.679 --> 00:58:14.039
<v Speaker 3>To just have the two versions in your code. Just

1038
00:58:14.159 --> 00:58:17.800
<v Speaker 3>have two versions of that event in two different namespaces

1039
00:58:17.880 --> 00:58:19.920
<v Speaker 3>or with two different class names or whatever. And that

1040
00:58:20.039 --> 00:58:20.679
<v Speaker 3>works fine.

1041
00:58:20.719 --> 00:58:23.159
<v Speaker 2>But that because how sweet do you think we're only

1042
00:58:23.199 --> 00:58:23.920
<v Speaker 2>going to have two?

1043
00:58:25.840 --> 00:58:28.639
<v Speaker 3>That becomes a mess over time, And then you start,

1044
00:58:29.199 --> 00:58:34.719
<v Speaker 3>Then you start practicing things like upcasting or but that's

1045
00:58:34.960 --> 00:58:39.519
<v Speaker 3>that's something that I tried to steer away from as

1046
00:58:39.639 --> 00:58:43.199
<v Speaker 3>long as I can, and ideally never do, is start

1047
00:58:43.400 --> 00:58:47.440
<v Speaker 3>updating the table and upcasting the events and resaving them

1048
00:58:47.559 --> 00:58:53.800
<v Speaker 3>too ideally new streams. But that's a tricky mechanism as well,

1049
00:58:53.880 --> 00:58:56.119
<v Speaker 3>because your new stream will have new eyelins to it.

1050
00:58:56.159 --> 00:58:59.280
<v Speaker 3>It's now incorrect, and it escalates, it escalates.

1051
00:58:59.320 --> 00:59:02.159
<v Speaker 1>I think when I hear you're saying, is higher harness

1052
00:59:02.320 --> 00:59:03.880
<v Speaker 1>if you want to tackle these problems?

1053
00:59:04.119 --> 00:59:07.039
<v Speaker 3>Yeah, well yeah, And there's there's a bunch of other

1054
00:59:07.159 --> 00:59:09.480
<v Speaker 3>people out there that do great work in this space

1055
00:59:09.559 --> 00:59:12.719
<v Speaker 3>as well. Like if you think about Oscar do for instance,

1056
00:59:13.400 --> 00:59:17.239
<v Speaker 3>you've met Oscar right. Oscar does some great stuff with

1057
00:59:17.400 --> 00:59:20.559
<v Speaker 3>events sourcing, and the whole d d D community seems

1058
00:59:20.639 --> 00:59:25.519
<v Speaker 3>to have adopted this as their pattern of choice. So

1059
00:59:25.599 --> 00:59:29.519
<v Speaker 3>there's many many people out there. But like think before

1060
00:59:29.639 --> 00:59:34.400
<v Speaker 3>you actually do this. And this works very well if

1061
00:59:34.480 --> 00:59:40.880
<v Speaker 3>you have complex domains that need to be modeled in

1062
00:59:41.079 --> 00:59:45.519
<v Speaker 3>code where you have high concurrency, for instance, because it's

1063
00:59:45.599 --> 00:59:49.480
<v Speaker 3>very good at dealing with that very explicit business logic.

1064
00:59:49.599 --> 00:59:51.679
<v Speaker 3>You don't want to have too many side effects. That's

1065
00:59:51.760 --> 00:59:56.639
<v Speaker 3>a very good reason to choose for this, But in general,

1066
00:59:56.800 --> 01:00:01.119
<v Speaker 3>as soon as you become proficient at this, you start

1067
01:00:01.199 --> 01:00:04.159
<v Speaker 3>using it for a lot more things because it's.

1068
01:00:04.159 --> 01:00:06.440
<v Speaker 2>Just so easy. Yeah, it's definitely. It sounds like a

1069
01:00:06.519 --> 01:00:08.760
<v Speaker 2>pattern that once you get the groove, you see places

1070
01:00:08.800 --> 01:00:10.840
<v Speaker 2>to use it. But it's not everything.

1071
01:00:11.079 --> 01:00:14.280
<v Speaker 3>It's just you have to flip the switch in your

1072
01:00:14.440 --> 01:00:18.880
<v Speaker 3>brain and for me, that live cycle of command comes in.

1073
01:00:19.119 --> 01:00:24.000
<v Speaker 3>We replay events, then we execute our business logic and

1074
01:00:24.159 --> 01:00:26.760
<v Speaker 3>that spawns new events which we now append to the

1075
01:00:26.800 --> 01:00:29.840
<v Speaker 3>stream again. As soon as that clicks in your head

1076
01:00:30.800 --> 01:00:34.840
<v Speaker 3>like it's no, it's not harder or easier than working

1077
01:00:35.000 --> 01:00:39.559
<v Speaker 3>with normal entities that you're pulling through entity framework from

1078
01:00:39.639 --> 01:00:41.880
<v Speaker 3>your r M and then calling safe changes. I mean,

1079
01:00:41.960 --> 01:00:46.400
<v Speaker 3>it's it's it's a trivial, a trivial amount of thinking

1080
01:00:46.840 --> 01:00:48.800
<v Speaker 3>to fit that in.

1081
01:00:49.079 --> 01:00:51.320
<v Speaker 2>Well, honess what's next for you? What are you doing?

1082
01:00:52.320 --> 01:00:53.159
<v Speaker 2>What's in your inbox?

1083
01:00:53.320 --> 01:00:57.880
<v Speaker 3>I'm leaving on holiday tomorrow or where you're thinking about

1084
01:00:59.159 --> 01:01:01.719
<v Speaker 3>what's next for me professionally? Either you know where you're

1085
01:01:01.719 --> 01:01:05.719
<v Speaker 3>going so European, I'm going I'm going to the to

1086
01:01:05.840 --> 01:01:09.000
<v Speaker 3>the Dutch coast with my family. We're going to go

1087
01:01:09.079 --> 01:01:12.280
<v Speaker 3>to a little house that's actually on the beach, much

1088
01:01:12.519 --> 01:01:15.000
<v Speaker 3>like the way that Richard lives, but not as fans.

1089
01:01:15.079 --> 01:01:20.119
<v Speaker 2>Wow, no fancy, my place has been Okay, that's pretty we.

1090
01:01:21.880 --> 01:01:24.400
<v Speaker 3>We will have neighbors for instance, that we can see.

1091
01:01:30.760 --> 01:01:31.239
<v Speaker 2>The family.

1092
01:01:31.440 --> 01:01:33.599
<v Speaker 3>The family is going to to the ghost and and

1093
01:01:33.679 --> 01:01:36.519
<v Speaker 3>I'm gonna recuperate for a little bit because I've had

1094
01:01:36.559 --> 01:01:40.000
<v Speaker 3>a rough year, like renovating a house and and becoming

1095
01:01:40.039 --> 01:01:43.960
<v Speaker 3>an independent contractor for half of my time and making

1096
01:01:44.039 --> 01:01:47.880
<v Speaker 3>courses and all that sort of stuff. And what's next

1097
01:01:48.440 --> 01:01:53.199
<v Speaker 3>professionally what I'm hoping to do in the fall, because

1098
01:01:53.199 --> 01:01:56.280
<v Speaker 3>I've just released two courses on events sourcing on the

1099
01:01:56.320 --> 01:01:59.840
<v Speaker 3>Home Train and the second one. There's like two more

1100
01:02:00.079 --> 01:02:02.840
<v Speaker 3>chapters that I really want to make that aren't there yet,

1101
01:02:04.719 --> 01:02:06.760
<v Speaker 3>So that might be a thing that I'm that I'm

1102
01:02:06.800 --> 01:02:10.400
<v Speaker 3>going to do in the fall. Great. Yeah, while we're

1103
01:02:10.440 --> 01:02:13.880
<v Speaker 3>looking and it's looking like conference season is going to

1104
01:02:13.960 --> 01:02:19.360
<v Speaker 3>be busy from November to beginning December, so I'll probably

1105
01:02:19.480 --> 01:02:22.159
<v Speaker 3>run into you guys a couple of times somewhere somewhere.

1106
01:02:22.320 --> 01:02:25.920
<v Speaker 2>All right, Well, that man, this is great stuff. Thanks Hanas. Yeah,

1107
01:02:26.119 --> 01:02:26.800
<v Speaker 2>great talking to you.

1108
01:02:27.119 --> 01:02:29.760
<v Speaker 3>I was happy to be on the show and thanks

1109
01:02:29.800 --> 01:02:33.079
<v Speaker 3>for letting me rand a little bit about this thing

1110
01:02:33.119 --> 01:02:34.320
<v Speaker 3>that I'm really passionate about.

1111
01:02:34.400 --> 01:02:39.239
<v Speaker 2>Absolutely crazy explanation. Thanks so much, very clear, all right,

1112
01:02:39.440 --> 01:02:42.719
<v Speaker 2>and we'll talk to you next time on dot net rocks.

1113
01:03:03.880 --> 01:03:06.440
<v Speaker 4>Dot net Rocks is brought to you by Franklin's Net

1114
01:03:06.719 --> 01:03:10.639
<v Speaker 4>and produced by Pop Studios, a full service audio, video

1115
01:03:10.760 --> 01:03:14.760
<v Speaker 4>and post production facility located physically in New London, Connecticut,

1116
01:03:15.079 --> 01:03:19.280
<v Speaker 4>and of course in the cloud online at pwop dot com.

1117
01:03:20.079 --> 01:03:22.119
<v Speaker 4>Visit our website at d O T N E t

1118
01:03:22.440 --> 01:03:26.440
<v Speaker 4>R O c k S dot com for RSS feeds, downloads,

1119
01:03:26.599 --> 01:03:30.280
<v Speaker 4>mobile apps, comments, and access to the full archives going

1120
01:03:30.320 --> 01:03:33.719
<v Speaker 4>back to show number one, recorded in September two thousand

1121
01:03:33.719 --> 01:03:33.960
<v Speaker 4>and two.

1122
01:03:34.639 --> 01:03:35.239
<v Speaker 2>And make sure you.

1123
01:03:35.320 --> 01:03:38.360
<v Speaker 4>Check out our sponsors. They keep us in business. Now

1124
01:03:38.440 --> 01:03:40.679
<v Speaker 4>go write some code, See you next time.

1125
01:03:41.599 --> 01:03:43.440
<v Speaker 3>You got jam Vans

1126
01:03:45.480 --> 01:03:45.519
<v Speaker 2>And
