WEBVTT 1 00:00:01.000 --> 00:00:04.759 How'd you like to listen to dot net rocks with no ads? Easy? 2 00:00:05.320 --> 00:00:09.880 Become a patron For just five dollars a month you get access to a private 3 00:00:10.000 --> 00:00:14.400 RSS feed where all the shows have no ADS. Twenty dollars a month will 4 00:00:14.400 --> 00:00:18.800 get you that and a special dot net Rocks patron mug. Sign up now 5 00:00:18.839 --> 00:00:24.199 at Patreon dot dot net rocks dot com. Hey Carlin Richard here. As 6 00:00:24.239 --> 00:00:29.519 you may have heard, NDC is back offering their incredible in person conferences around 7 00:00:29.559 --> 00:00:33.320 the world, and we'd like to tell you about them. NDC Oslow will 8 00:00:33.359 --> 00:00:37.119 be made twenty first through the twenty fifth. Go to NDC Oslo dot com 9 00:00:37.159 --> 00:00:42.840 to register. NDC Copenhagen is happening August twenty seventh through the thirty first. 10 00:00:42.880 --> 00:00:48.880 The early bird discount for NDC Copenhagen ends June second. Go to NDC Copenhagen 11 00:00:48.960 --> 00:00:54.719 dot com for more information. NDC Porto is happening October sixteenth through the twentieth. 12 00:00:54.920 --> 00:00:59.000 The early bird discount for dc Porto ends July twenty first. Go to 13 00:00:59.079 --> 00:01:03.840 EDDC Porto dot column to register and check out the full lineup of conferences at 14 00:01:03.960 --> 00:01:11.599 NDC conferences dot com. Http timeouts Database deadlocks in software, it's not a 15 00:01:11.640 --> 00:01:15.959 matter of if things fail, it's a matter of when one mishap like this 16 00:01:17.239 --> 00:01:23.159 and some valuable data is lost forever. And these failures occur all the time, 17 00:01:23.719 --> 00:01:26.480 but it doesn't have to be this way. Introducing end service bus, 18 00:01:26.920 --> 00:01:33.319 the ultimate tool to build robust and reliable systems that can handle failures gracefully, 19 00:01:33.680 --> 00:01:38.519 maintain high availability, and scale to meet growing demand. For more than fifteen 20 00:01:38.599 --> 00:01:44.560 years, end service bus has been trusted to run mission critical systems that must 21 00:01:44.680 --> 00:01:49.400 not go down or lose any data ever. And now you can try it 22 00:01:49.439 --> 00:01:53.319 for yourself. End service bus integrates seamlessly with your dot net applications and can 23 00:01:53.359 --> 00:01:57.719 be hosted on premises or in the cloud. Say goodbye to loss data and 24 00:01:57.799 --> 00:02:04.159 system failures, and hello to a better, more reliable way of building distributed 25 00:02:04.200 --> 00:02:08.000 systems. Try end service bus today by heading over to go dot particular, 26 00:02:08.080 --> 00:02:15.840 dot net slash dot net rocks and start building better systems with asynchronous messaging using 27 00:02:15.919 --> 00:02:31.280 end service bus. Hey, guess what it's dot net and rocks. I'm 28 00:02:31.319 --> 00:02:36.120 Carl Franklin and I'm Richard Campbell. We're getting all of these shows done so 29 00:02:36.159 --> 00:02:39.560 that we can go travel for a bit going on adventures, going on adventures. 30 00:02:40.120 --> 00:02:45.319 We'll do more shows while we're adventuring too, And we're gonna be at 31 00:02:45.400 --> 00:02:51.080 Techarama in Belgium. And I believe you're going to Dot Net Developer Days twenty 32 00:02:51.080 --> 00:02:53.319 twenty three in Poland, right, yeah, in Warsaw Warsaw. I'll be 33 00:02:53.360 --> 00:02:57.400 there, but I think I have the opening keynote. Actually, yeah, 34 00:02:57.400 --> 00:03:00.439 that's cool. I don't know for sure, but it's possible I be there, 35 00:03:00.479 --> 00:03:04.000 But if you want to check it out and you're anywhere near Poland in 36 00:03:04.319 --> 00:03:09.680 October, it's net dot Developer Days dot PL. It's a it's a great 37 00:03:09.719 --> 00:03:13.120 conference. I went there a couple of years ago and I had a great 38 00:03:13.159 --> 00:03:15.560 time. Yeah, we had a ton of fun there. Yeah. Okay, 39 00:03:15.599 --> 00:03:17.159 anyway, let's get right to the meat of it with better no framework. 40 00:03:24.759 --> 00:03:27.759 All right, man, what do you got? All right? So 41 00:03:28.400 --> 00:03:34.879 this is a blog post by Eric Elliott March thirty first on medium dot com. 42 00:03:35.360 --> 00:03:39.800 This guy has written a pseudocode programming language. I almost said pseudacu. 43 00:03:40.360 --> 00:03:46.800 A pseudo code programming language for large language models. And it's called pseudo lang 44 00:03:47.120 --> 00:03:53.240 sud O l A n G. See what he did there, Yeah, 45 00:03:53.280 --> 00:03:58.759 and so he's been using pseudocode to express ideas to large language models since GPT 46 00:03:58.960 --> 00:04:02.800 three. However, up until GPD four it didn't work extremely well. But 47 00:04:02.879 --> 00:04:11.360 then he's working on it, and I haven't used it. But there's a 48 00:04:11.400 --> 00:04:15.040 whole bunch of statistics and stuff in there, and he says, here's some 49 00:04:15.160 --> 00:04:20.519 commands and some modifiers and examples and it, and it looks good. I 50 00:04:20.560 --> 00:04:25.519 don't know, it seems pretty complex. I mean, isn't English a pseudo 51 00:04:25.600 --> 00:04:30.600 language in the first place? You would thinks so, yes, But I 52 00:04:30.600 --> 00:04:34.920 guess it's somewhere between a programming language and natural language. But there I thought 53 00:04:34.920 --> 00:04:40.480 the whole idea of large language models was to use language, right, I 54 00:04:40.519 --> 00:04:43.360 think that's what you're saying, right. I don't know. I can't really 55 00:04:43.439 --> 00:04:46.920 judge it because I haven't really read through it. So I thought it was 56 00:04:46.000 --> 00:04:50.120 interesting and came across my desk. And since you know, we're in the 57 00:04:50.199 --> 00:04:56.199 hype cycle of GPT large language models and all of that stuff, people are 58 00:04:56.199 --> 00:05:00.199 going to start dipping their toes in tools to make them more powerful, right, 59 00:05:00.399 --> 00:05:03.639 So somebody should check that out and get back to us and let us 60 00:05:03.639 --> 00:05:08.079 know how cool it is. All it's all explorations at this point, but 61 00:05:08.120 --> 00:05:11.560 interesting ones. It is certainly interesting. It was talking to us today Richard 62 00:05:11.600 --> 00:05:15.439 grabbed a comment offer. Show eighteen o nine is one we did about microservices 63 00:05:15.480 --> 00:05:19.199 architecture with our friend Shawn Wildermouth. Step back in follow twenty twenty two, 64 00:05:19.800 --> 00:05:24.680 Bart Lenois said, Carl, Richard and Sean thanks a lot for the show. 65 00:05:24.879 --> 00:05:27.120 These days, you seem to be doing something wrong if you're not using 66 00:05:27.120 --> 00:05:31.600 microservices and Kubernetes. It's like everyone forgot about the kiss principle and they have 67 00:05:31.680 --> 00:05:36.319 this battle with almost every client. There's nothing wrong with a well architect monolith 68 00:05:36.600 --> 00:05:42.199 or service already an architecture and deploying a handful of services on Azure, app 69 00:05:42.240 --> 00:05:46.519 service or functions as minutes of work with minimal skill required. Only a small 70 00:05:46.560 --> 00:05:49.319 percentage come to the point where they need full blown microservices architecture, and if 71 00:05:49.360 --> 00:05:54.720 you're googling for it, you're not one of them. Listen, Bart, 72 00:05:54.800 --> 00:05:58.879 here's your solution. When the customer says I would like some Kubernetes please, 73 00:05:59.199 --> 00:06:02.079 you get us a bottle, put a big logo on it says Kubernetes, 74 00:06:02.240 --> 00:06:05.560 and you squirted on them. And then if you're really smart, you say 75 00:06:05.920 --> 00:06:13.399 no. And I got to remind everybody that the kiss principle is and I 76 00:06:13.480 --> 00:06:26.160 quote you gotta lose your mind in Detroit Rock City. But I really appreciate 77 00:06:26.160 --> 00:06:29.079 this comment from Bart just because it's like, listen, there's not one way 78 00:06:29.120 --> 00:06:33.319 to solve every problem. And if you're determining a technology before you've argetted an 79 00:06:33.360 --> 00:06:39.160 application, you have are on the wrong path. Right like that, It's 80 00:06:39.279 --> 00:06:42.600 that's just a given. Let's look at the problem space first, then we 81 00:06:42.639 --> 00:06:45.360 can talk about what we build. So Bort, thank you so much for 82 00:06:45.360 --> 00:06:46.759 your comment, and a copy of music cobuy is on its way to you. 83 00:06:46.959 --> 00:06:49.120 And if you'd like a copy of music co buy, write a comment 84 00:06:49.160 --> 00:06:53.519 on the website at dot net rocks dot com or on Facebook. We publish 85 00:06:53.600 --> 00:06:56.360 every show there and if I read your comment, I'll send you a copy 86 00:06:56.360 --> 00:06:58.720 of music cobuy. And you know, you can follow us on Twitter. 87 00:06:58.800 --> 00:07:00.879 That's all cool, but it would be really cool if you followed us on 88 00:07:01.079 --> 00:07:05.160 mastadon because that's where all the cool kids are these days. I'm at Carl 89 00:07:05.199 --> 00:07:10.560 Franklin at tech hub dot social, and I'm Rich Campbell at mast social and 90 00:07:10.680 --> 00:07:15.199 send us to two we'd like to hear from you. And that brings us 91 00:07:15.199 --> 00:07:18.480 to our friend Michael Perry, who I was shocked that we haven't had him 92 00:07:18.519 --> 00:07:21.759 on dot net rocks, but we did have him on the tablet show back 93 00:07:21.759 --> 00:07:26.680 in the day. So I guess everything just ran together in my brain and 94 00:07:26.720 --> 00:07:29.680 I'm well, it's it's not like we don't see mcconferences all the time, 95 00:07:29.839 --> 00:07:33.040 all four times. He's part of the circle. But we were roommates. 96 00:07:33.120 --> 00:07:38.399 Embarrassingly, we never did this show for crying out loud an MVP summit. 97 00:07:38.439 --> 00:07:41.480 Weren't we weren't we roommates? Yes, we were. We were roommates. 98 00:07:41.800 --> 00:07:44.600 Yeah, we didn't choose to be. It was just like, hey, 99 00:07:44.680 --> 00:07:50.000 I know you, so let me formally introduce Michael Perry. Software is math. 100 00:07:50.759 --> 00:07:56.319 Every class is a theorem, the compiler is the proof, and unit 101 00:07:56.399 --> 00:08:01.519 tests check our work. Michael Perry has built upon the works of mathematicians like 102 00:08:01.600 --> 00:08:07.800 Mark Shapiro, Pat helland and Leslie Lamport to develop a mathematical system for software 103 00:08:07.839 --> 00:08:13.519 development. He has captured this system in a set of open source projects Jinga 104 00:08:13.680 --> 00:08:20.480 and assisticant. I love assistant. Yeah that was my daughter's name. What 105 00:08:22.360 --> 00:08:26.519 yeah, Yeah, Well, when my daughter Kayla, whenever she thought her 106 00:08:26.560 --> 00:08:31.879 name was assisticant. No, but whenever she would help her mother out at 107 00:08:31.000 --> 00:08:35.279 a at a show, then you know she would ask, Hey, can 108 00:08:35.279 --> 00:08:37.480 it come along and be your assisticant. Oh that's so cool, that's great. 109 00:08:37.519 --> 00:08:41.600 I love that. It's almost like something that goes in a squirt bottle 110 00:08:41.600 --> 00:08:46.960 for Kubernetes. Isn't it a little assisticant? And yeah? Well anyway, 111 00:08:46.039 --> 00:08:50.799 great, great to have you on the show. And just your bio sort 112 00:08:50.799 --> 00:08:52.279 of sets the tone for what we're going to talk about here, doesn't it. 113 00:08:52.320 --> 00:08:56.519 This is really fascinating to me. Yeah. In fact, the other 114 00:08:56.519 --> 00:09:00.679 open spurs project is pronounced in Janaka. It's oh what did I say? 115 00:09:00.759 --> 00:09:05.279 Jenga yeah? Jinga yeah, yeah. Yeah. It's not the the tower 116 00:09:05.320 --> 00:09:07.799 of bricks that are going to fall down on you. It's it's much more 117 00:09:07.840 --> 00:09:13.200 staple than that, ji Naga. So what is Janaga? Yeah? Janaga 118 00:09:13.399 --> 00:09:20.639 is a platform for UM for managing data in a in a distributed system UM. 119 00:09:20.720 --> 00:09:24.559 One of the great examples is in a mobile application. If you think 120 00:09:24.600 --> 00:09:31.679 about each mobile device being its own separate node within the within the network UM, 121 00:09:31.759 --> 00:09:35.399 then you can you can have your your data on your mobile device, 122 00:09:35.799 --> 00:09:39.639 interact with it as a user, and then it uh um, it kind 123 00:09:39.679 --> 00:09:46.200 of sinks up with the replicator, uh and you get that eventual consistency. 124 00:09:46.720 --> 00:09:50.879 So yeah, Janaga is a way to to turn your micro services mobile applications, 125 00:09:50.919 --> 00:09:58.120 web applications into these uh, these small isolated nodes that eventually will reach 126 00:09:58.159 --> 00:10:03.360 agreement. It's interesting. And Assisticant is what. Yeah. Assisticant is a 127 00:10:03.399 --> 00:10:09.519 is an MVVM framework um that is based on the idea of dependency tracking. 128 00:10:09.360 --> 00:10:15.799 If you remember, you know, Steve Sanders Sanderson's old knockout, Yeah your 129 00:10:15.919 --> 00:10:20.919 library. Yeah, that's uh, that's the same the same algorithm that it 130 00:10:20.919 --> 00:10:26.919 It figures out what depends about what, so that when something changes it it 131 00:10:26.039 --> 00:10:33.080 notifies the dependent Wow. And so you're talking large object models, then yeah, 132 00:10:33.080 --> 00:10:37.320 I tend to use assisticant for the the smaller focused like this is going 133 00:10:37.360 --> 00:10:41.559 to be a view model for just a single page, or even a composite 134 00:10:41.639 --> 00:10:43.519 view model with the you know, you know, a page that has a 135 00:10:43.559 --> 00:10:48.039 list in each one of those elements in the list is its own smaller view 136 00:10:48.080 --> 00:10:54.039 model. That's what I tend to use assisticant for, not so much for 137 00:10:54.080 --> 00:11:00.879 the larger ones. So some m MVVM frameworks come with sort of communication tools 138 00:11:00.879 --> 00:11:03.960 of one kind or another, don't they. Yeah, yeah, yeah. 139 00:11:03.120 --> 00:11:05.519 A lot of times when you see MBVM, it's like, how do I 140 00:11:05.519 --> 00:11:09.360 implement I not if I reputy changed, And I'm like, oh, let's 141 00:11:09.360 --> 00:11:16.360 take a step back. Let's not try to implement the programming problem at hand, 142 00:11:16.440 --> 00:11:20.759 but instead try to specify the desired behavior. Yeah. Sure, and 143 00:11:20.799 --> 00:11:26.720 then let the computer figure out how to how to give you that that desired 144 00:11:26.720 --> 00:11:30.679 behavior. Or we could just use Blazer It's true. Yeah, yeah, 145 00:11:30.679 --> 00:11:33.519 Blazer is a fantastic isn't it great? Just love it? All right, 146 00:11:33.639 --> 00:11:41.720 So we're talking about how does this incredible bio here that you know that you've 147 00:11:41.720 --> 00:11:48.159 built these this mathematical system for software development and I guess your two projects that 148 00:11:48.240 --> 00:11:52.120 you talk about illustrate this. But um, how does that align with the 149 00:11:52.320 --> 00:11:58.360 idea of immutable architectures? Yeah? Yeah, So this is this kind of 150 00:11:58.360 --> 00:12:03.679 goes back to UM. If you look at those mathematicitions I mentioned their Mark 151 00:12:03.720 --> 00:12:09.879 Shapiro, that first one he and UH and his co author Nuna Pergucia basically 152 00:12:09.879 --> 00:12:16.799 published the very first c RDT specification. That's a conflict free replicated data type 153 00:12:18.360 --> 00:12:26.159 UM. This is a mathematical object that has some amazing properties in that it 154 00:12:26.240 --> 00:12:31.879 will reach eventual consistency. So it will reach consistency as soon as all of 155 00:12:31.879 --> 00:12:37.320 the nodes have received all of the information eventual consistency. Because this doesn't come 156 00:12:37.399 --> 00:12:41.360 up often on dot net rocks, but this is the idea that I have 157 00:12:43.159 --> 00:12:46.600 object A with a state, and when that state changes, eventually Object B 158 00:12:46.879 --> 00:12:50.399 that is some sort of replicant of it is going to change, whether that's 159 00:12:50.399 --> 00:12:54.480 a database or whatever, eventually. Yeah, yeah, exactly. Yeah. 160 00:12:54.559 --> 00:13:00.639 And and what's really exciting about that so that you might have heard of algorithms 161 00:13:00.679 --> 00:13:05.679 like paxos that are based on consensus. So so these different nodes have to 162 00:13:05.679 --> 00:13:09.440 collaborate with one another, They have to you know, chat back and forth 163 00:13:09.480 --> 00:13:13.320 in order to come to an agreement who's going to have the correct state. 164 00:13:15.360 --> 00:13:20.639 In the case of a c RTT, the way that the data structure works 165 00:13:22.000 --> 00:13:26.159 will guarantee that as soon as they all receive the same information, they are 166 00:13:26.200 --> 00:13:31.480 in the same state. They don't have to go through this extra this extra 167 00:13:31.799 --> 00:13:35.960 checks and balances. Yeah, it's pretty cool stuff. That is cool. 168 00:13:35.159 --> 00:13:39.080 Yeah, Well, it's interesting to have the stuff's sort of solved models, 169 00:13:39.159 --> 00:13:46.039 right, Like they're exemplars or design patterns even of how you should build these 170 00:13:46.120 --> 00:13:50.519 kinds of problems, like you should not invent a new implementation of eventual consistency. 171 00:13:50.799 --> 00:13:54.720 Right. Yeah, it's very easy to be wrong. It's very difficult 172 00:13:54.759 --> 00:14:00.480 to detect that you're wrong and it is a solved problem. Yeah, yeah, 173 00:14:00.559 --> 00:14:03.320 it's UM. It's very similar to what I was just saying about, 174 00:14:03.840 --> 00:14:09.559 write the specification and let the computer figure out the implementation. Computers are really 175 00:14:09.600 --> 00:14:13.080 good at computation. Yea. They can take an equation, they can solve 176 00:14:13.080 --> 00:14:16.879 it, they can give you the correct answer. You give a human that 177 00:14:18.000 --> 00:14:20.519 same problem, you're not going to make mistakes. UM. But now if 178 00:14:20.879 --> 00:14:26.000 if the human approaches that problem but instead and writes a specification, now what 179 00:14:26.039 --> 00:14:30.200 they're doing is they're they're giving the computer the equation. They're saying, I 180 00:14:30.360 --> 00:14:33.399 want you to produce the system that does this. Um. You know, 181 00:14:33.480 --> 00:14:37.240 like you know, taking it back to cr dts UM. One of the 182 00:14:37.919 --> 00:14:43.919 one of the first c r dts that UM that the Mark Shapiro and No 183 00:14:43.000 --> 00:14:50.960 Prusia published was tree doc. This is a cr DT that UM that supports 184 00:14:52.399 --> 00:14:56.120 collaborative editing of text documents. So, um, so, if you're familiar 185 00:14:56.159 --> 00:15:00.720 with Google Docs, Google docs doesn't actually use this algorithm, using something else 186 00:15:00.759 --> 00:15:07.120 called operational transforms, which are known to have defects. But if they had 187 00:15:07.279 --> 00:15:11.399 used tree doc then basically by specifying okay, these are the rules of the 188 00:15:11.600 --> 00:15:18.919 r DT computer, you come up with the implementation. Then by using the 189 00:15:18.360 --> 00:15:22.279 mathematics of crdts, it would be able to come up with a correct implementation 190 00:15:22.399 --> 00:15:28.000 of collaborative text editor. Michael, did your interest in computers and maths sort 191 00:15:28.000 --> 00:15:31.639 of grow at the same rate or what? Was there a period in your 192 00:15:31.639 --> 00:15:35.480 life when you were all math and computers came out to that man, Yeah, 193 00:15:35.519 --> 00:15:39.840 I think I think they pretty much did grow at the same rate. 194 00:15:41.159 --> 00:15:48.399 That's cool, but yeahs, I've just always loved the mathematical side of software. 195 00:15:48.639 --> 00:15:50.440 Yeah, that we've seen it as applied math. That's a very unique 196 00:15:50.440 --> 00:15:54.200 place to come from for software developers, isn't it, because you know, 197 00:15:54.279 --> 00:16:00.840 you get to experiment with both models at the same time. Yeah. Yeah, 198 00:16:00.879 --> 00:16:03.919 and you end up with some really surprising results too. You know, 199 00:16:03.000 --> 00:16:07.519 some things that that people don't expect to work, Like when I show people 200 00:16:07.600 --> 00:16:12.120 assisticant um it's like, well, yeah, it's it's a very simple idea. 201 00:16:12.200 --> 00:16:15.879 You write it um like a property getter, for example, write a 202 00:16:15.919 --> 00:16:21.960 property getter UM. And if it's going to reach out and get values from 203 00:16:22.000 --> 00:16:26.759 other uh from other properties, then you know that it depends upon those So 204 00:16:26.879 --> 00:16:32.000 why not just have the computer watch while it's executing that and see what it 205 00:16:32.080 --> 00:16:36.240 does. And now you've just tracked your dependencies and so whenever those things change, 206 00:16:36.480 --> 00:16:38.279 this property has changed, um. And so it's like, well, 207 00:16:38.360 --> 00:16:42.000 yeah, that that makes sense. That follows logically one from from the next. 208 00:16:42.039 --> 00:16:47.559 You've basically just told me a proof uh that that you're going to get 209 00:16:47.600 --> 00:16:51.519 the correct behavior out of a dependency tracking system. And then you actually, 210 00:16:51.720 --> 00:16:55.120 well then here's an implementation of it. Let's run it and it works, 211 00:16:55.159 --> 00:16:59.639 and it's like it's magic. It's like I just explain it to you. 212 00:17:00.639 --> 00:17:03.879 Very reliable math at that. Yeah. Of course, many of the original 213 00:17:03.879 --> 00:17:08.039 computer people were mathematicians. I mean, fundamentally we're still all using von Yuman 214 00:17:08.160 --> 00:17:12.440 machines. And von Neuman was a mathematician. The question is if he wasn't 215 00:17:12.440 --> 00:17:15.839 born in a day where there was no computers, would it be an a 216 00:17:17.240 --> 00:17:19.839 computer scientist rather than a mathematician, Like you didn't. You didn't really have 217 00:17:19.839 --> 00:17:23.319 a choice but to be a mathematician and end up in computing. That was 218 00:17:23.359 --> 00:17:26.960 the path for that time, that era. Yeah, yeah, that's true. 219 00:17:27.000 --> 00:17:30.559 And yeah, if i'd if i'd have been born, you know, 220 00:17:30.839 --> 00:17:33.960 you know, fifty years earlier, Yeah, I would have just been a 221 00:17:33.000 --> 00:17:36.440 pure mathematicians, you probably would have gone into maths, right, Like, 222 00:17:36.519 --> 00:17:37.839 that's kind of you don't really have a choice. It's like, if you 223 00:17:37.920 --> 00:17:42.240 like that purity of problem solving, that's pretty much the only place it lives. 224 00:17:42.359 --> 00:17:47.440 You know. When I was in college and taking a computer science course, 225 00:17:47.480 --> 00:17:52.559 the computer teacher said you kind of gotta love math to get into it. 226 00:17:52.039 --> 00:17:56.480 And she couldn't have been more wrong. I mean, the right right 227 00:17:56.680 --> 00:18:02.440 brain programming ideas were blooming in the nineties, like and she was just out 228 00:18:02.480 --> 00:18:07.279 of punch. You know. It wasn't all Fortran and you know and calculus 229 00:18:07.359 --> 00:18:11.039 programming and stuff. It was you know, we were talking about business logic, 230 00:18:11.119 --> 00:18:15.119 and we were talking about language and all of these things that computers could 231 00:18:15.160 --> 00:18:18.160 do. So so I got into it from a rape brain. Obviously, 232 00:18:18.279 --> 00:18:22.640 music is like, you know, music and computers sort of grew in my 233 00:18:22.680 --> 00:18:26.559 brain at the same time. And and you know, so it's fascinating to 234 00:18:26.599 --> 00:18:30.720 me to find a species from the other side of the world the left brain 235 00:18:30.759 --> 00:18:37.000 approach, um, because you know that that's completely opposite to my experience. 236 00:18:37.359 --> 00:18:40.160 So, and I don't know about the rest of the you know, people 237 00:18:40.200 --> 00:18:44.400 out here, but the hardcore engineers that right, operating systems and stuff and 238 00:18:44.640 --> 00:18:48.799 right, you know, serious stuff with computer science degrees, they're they're certainly 239 00:18:49.440 --> 00:18:56.759 more into the maths. But guys like you obviously who thought about really carefully 240 00:18:56.799 --> 00:19:00.279 thought about how these mathematical mathematical models play out and software. Yeah, isn't 241 00:19:00.319 --> 00:19:07.000 this a wonderful industry, so much diversity. There's room for all types of 242 00:19:07.000 --> 00:19:11.440 thought. Absolutely, Yeah, and they they dressed different parts of the problem 243 00:19:11.519 --> 00:19:14.960 space. Like it's not like us is running out of work. There's lots 244 00:19:14.960 --> 00:19:19.400 and lots to do. But yeah, the the idea that you, you 245 00:19:19.440 --> 00:19:22.279 know, you have to love math to be involved in computing is just no 246 00:19:22.319 --> 00:19:29.039 longer correct. Yeah, there are elements of computing that certainly well served by 247 00:19:29.119 --> 00:19:33.359 math. But look, there are good tree negotiation strategies. They're APIs now 248 00:19:33.680 --> 00:19:37.519 you don't need to write one. Oh, yeah, you're good I still 249 00:19:37.559 --> 00:19:41.440 think that in order to do just basic stuff, especially any kind of UI 250 00:19:41.640 --> 00:19:45.440 kind of need to know a few a few things. He needs to know 251 00:19:45.559 --> 00:19:48.680 ratios, he needs to know, you know, algebra a little bit, 252 00:19:48.359 --> 00:19:52.480 but it's not it's about it yet, you know, maybe a little trigonometry. 253 00:19:52.519 --> 00:19:56.279 I was working on some connects stuff and I needed some trigg and that 254 00:19:56.440 --> 00:20:00.039 was mind blowing. Yeah, and I think that I think there's a difference 255 00:20:00.079 --> 00:20:07.960 between them. The subjects of math that we just talked about, the trigonometry 256 00:20:07.039 --> 00:20:15.559 and algebra and even some calculus. Um, but then there's also the mathematical 257 00:20:15.599 --> 00:20:22.200 thinking, this logical way of thinking. So um to one thing, I 258 00:20:22.279 --> 00:20:25.039 like to say when people ask, well, do you have to be good 259 00:20:25.039 --> 00:20:27.400 at math in order to program? And no, No, math and programming 260 00:20:27.400 --> 00:20:33.880 they're completely different to operations. In math, you're taking symbols and you're you're 261 00:20:33.960 --> 00:20:37.440 manipulating these abstract concepts in order to come up with a solution, whereas in 262 00:20:37.519 --> 00:20:41.240 programming you're taking symbols and manipulating these abstract concepts in order to come up with 263 00:20:41.240 --> 00:20:48.119 a solution. Comparing the different things, yeah, just the shape of the 264 00:20:48.160 --> 00:20:52.759 symbols. Well, and really, who's the compiler today exactly. That's the 265 00:20:52.799 --> 00:20:55.720 difference. Yeah. So I like to think, um, it's not that 266 00:20:55.759 --> 00:20:57.160 you have to be good at math in order to be a good programmers that 267 00:20:57.319 --> 00:21:02.720 if you're a good programmer, you're good at math. You just didn't realize 268 00:21:02.720 --> 00:21:06.440 it, right, Yeah. Yeah. If you learn the if your learn 269 00:21:06.519 --> 00:21:08.759 the rules of symbolic math, you'll find you're already thinking that way, right. 270 00:21:10.319 --> 00:21:14.359 Yeah. So where's the immutable part come from? Too? Yeah? 271 00:21:14.359 --> 00:21:18.640 So, um so it turns out that's one of the um one of the 272 00:21:18.680 --> 00:21:26.599 best cr dts. Um is a directed a cyclic graph of immutable records. 273 00:21:26.720 --> 00:21:30.680 So one more time, CRDT, just one more time. The Yeah yeah, 274 00:21:30.759 --> 00:21:36.960 CRT is a conflict free replicated data type. Okay. Um So, 275 00:21:36.960 --> 00:21:41.200 so by a data type we mean a data structure plus operations. Um So, 276 00:21:41.359 --> 00:21:44.920 just like a linklest the data structure, if you will. But it's 277 00:21:44.920 --> 00:21:48.240 also got some operations and so that pair, that combination makes it a data 278 00:21:48.240 --> 00:21:52.640 type. That's ok, it's useful. Um. So, a conflict free 279 00:21:52.000 --> 00:21:57.119 replicated data type is a data type some structure and some operations that live on 280 00:21:57.200 --> 00:22:03.000 different replicas, different different nodes. Um. And it's conflict free because as 281 00:22:03.079 --> 00:22:07.000 you perform those operations, you will never get this, uh, this cr 282 00:22:07.079 --> 00:22:11.880 DT to be in a state of conflict on two different nodes. In other 283 00:22:11.880 --> 00:22:17.599 words, no dependencies. It's it's it's it's pretty cool. Um. We 284 00:22:17.599 --> 00:22:22.319 can actually tie this right back to the best implementation of an immutable cr DT 285 00:22:23.000 --> 00:22:26.640 that just about everybody listening to the show should be familiar with, and that 286 00:22:26.759 --> 00:22:32.720 is GET. Okay, In GET, you you make a change, you 287 00:22:32.720 --> 00:22:37.640 you create a commit. A commit is an immutable record of the change that 288 00:22:37.680 --> 00:22:41.319 you just made, right, and part of that record is who made it 289 00:22:41.400 --> 00:22:45.279 when, what was the commit comment? You know, where the contents of 290 00:22:45.279 --> 00:22:52.160 the commit, but also what is the identity of the prior commit um? 291 00:22:52.480 --> 00:22:56.759 And then GET will take all that together, put that into a data structure, 292 00:22:56.799 --> 00:22:59.559 compute the SHAW to BT six hash of it, and say, okay, 293 00:22:59.640 --> 00:23:02.480 that's the identity of this commit. Right now, you create another one, 294 00:23:03.279 --> 00:23:06.400 okay, collects all the information, and then what is the identity of 295 00:23:06.400 --> 00:23:08.599 the previous one? What's the previous shot? I got it? And so 296 00:23:10.119 --> 00:23:14.599 by creating that that reference from one record back to the previous one, you're 297 00:23:14.640 --> 00:23:19.039 creating a directed a cyclic graph. So it's directed, it's always pointing back 298 00:23:19.079 --> 00:23:22.160 to the past. Here's the prior commit, here's the prior commit. UM. 299 00:23:22.400 --> 00:23:26.200 And it's a cyclic because there's no way for you to make a commit 300 00:23:26.720 --> 00:23:32.240 that will then refer to something that comes loops back around and points back to 301 00:23:32.279 --> 00:23:37.240 itself. Yeah, so sort of the journal of pattern. Yeah there if 302 00:23:37.279 --> 00:23:42.440 you will, Yeah, yeah, exactly, yeah and and um so so 303 00:23:42.640 --> 00:23:48.960 I would I would call GET an example of an immutable architecture UM. There 304 00:23:48.000 --> 00:23:53.519 are there are a few other examples of immutable architectures UM, and so some 305 00:23:55.039 --> 00:24:00.319 are very similar to GET, like blockchain UM, in that you elect a 306 00:24:00.319 --> 00:24:03.160 bunch of transactions, you have the hash of the previous block, and you 307 00:24:03.440 --> 00:24:07.759 compute it's hash, and now that's the reference to the new one. Right. 308 00:24:08.160 --> 00:24:11.720 The difference is that blockchain requires proof of work in order to make sure 309 00:24:11.759 --> 00:24:17.759 that that chain never never forks, whereas GET forks are a feature, not 310 00:24:17.839 --> 00:24:21.960 a bug. Yeah, we're calling branches and that's how we do work. 311 00:24:22.279 --> 00:24:25.559 But the main thing area is no information is ever destroyed. Right, it's 312 00:24:25.559 --> 00:24:29.480 immutable, it's always there, exactly. I mean we've advocated for this and 313 00:24:29.599 --> 00:24:33.000 databases for the longest time. Is these sort of insert only tables journal style 314 00:24:33.079 --> 00:24:37.319 tables because we want like a bank, we want a record of every motion 315 00:24:37.359 --> 00:24:42.039 of money, every change, even if the sums come later. Right, 316 00:24:42.119 --> 00:24:47.039 and more important is just the motion. Yeah, exactly, exactly, Yeah, 317 00:24:47.039 --> 00:24:48.519 you need that immutable history. Yeah, except then when you got to 318 00:24:48.559 --> 00:24:52.400 do a report. So immutable architecture is one where data is never destroyed, 319 00:24:52.559 --> 00:24:56.759 right, right, Not great for reporting, Nope, not great for reporting 320 00:24:56.920 --> 00:25:00.119 at all. Yeah, use something up for that. Yeah, but but 321 00:25:00.200 --> 00:25:03.680 yeah. Another another example that that people might already be familiar with is event 322 00:25:03.720 --> 00:25:08.839 sourcing. So that is a third immutable architecture. I would say in that 323 00:25:08.880 --> 00:25:15.079 list that basically, UM, there has to be some stream that puts those 324 00:25:15.119 --> 00:25:19.279 events into a sequence, or at least in a piece wise sequence. So 325 00:25:19.359 --> 00:25:23.759 for this particular aggregate, these are the sequence of events that have occurred. 326 00:25:25.119 --> 00:25:27.200 And now from that you can compute the current state. Right, And so 327 00:25:27.279 --> 00:25:33.680 a lot of people build applications using using events sourcing UM. In in my 328 00:25:33.720 --> 00:25:38.880 book The Art of Immutable Architecture, I introduce a fourth immutable architecture that I 329 00:25:40.000 --> 00:25:45.559 call historical modeling that is also suitable for building applications, but has some of 330 00:25:45.599 --> 00:25:52.680 the advantages of get UM as compared to things like events sourcing. Okay, 331 00:25:52.880 --> 00:25:56.880 so your product Jannaga, did I say it right? Yes? Okay, 332 00:25:56.960 --> 00:26:02.039 perfect? So you said this is sort of it kind of sounds like an 333 00:26:02.079 --> 00:26:06.480 actor model pattern for mobile, but not really because an actor model has like 334 00:26:06.559 --> 00:26:12.160 these these actors um in memory on a server somewhere that represent a client. 335 00:26:12.400 --> 00:26:15.880 Yeah, isn't that right? So this is a little bit different, isn't 336 00:26:15.880 --> 00:26:18.640 that? Yeah, it is a bit different. Um. And And another 337 00:26:18.680 --> 00:26:23.440 significant difference is that with the actor model UM, the actors have mutable states. 338 00:26:23.759 --> 00:26:26.079 Right, you send a message to an actor, it can load a 339 00:26:26.160 --> 00:26:30.240 state, mutated, save it back and tell you what the answer is, 340 00:26:30.359 --> 00:26:36.680 right, whereas with an immutable architecture, mutation forbidden, right right, just 341 00:26:36.759 --> 00:26:40.480 not not a thing you must love f sharp I actually do. Yeah, 342 00:26:40.480 --> 00:26:42.319 I don't. I can't do to program it very much. But you know 343 00:26:42.400 --> 00:26:47.759 now that that dot net has records, Yeah, it's like, oh man, 344 00:26:47.799 --> 00:26:52.200 I'm all over those records. So so yeah, the the new version 345 00:26:52.200 --> 00:26:56.839 of Jenaga that I'm working on right now, Jenaga, that net um is 346 00:26:56.599 --> 00:27:02.079 taking full advantage of those immutable records. Yeah, yeah, yeah, yeah. 347 00:27:02.119 --> 00:27:03.920 The wait till wait till you see how the how the code looks. 348 00:27:03.960 --> 00:27:07.799 It's amazing that's very cool. Does the enthusiasm for this? I mean, 349 00:27:07.960 --> 00:27:11.599 to me is a guy who's usually worked on performance problems. What I like 350 00:27:11.680 --> 00:27:17.759 about all these immutable architectures is they perform very well because they avoid contention, 351 00:27:17.839 --> 00:27:21.880 which is usually your performance problem. I mean, is that a reason to 352 00:27:22.000 --> 00:27:25.039 do it? Like? Why else would you want immutable architectures? Yeah? 353 00:27:25.079 --> 00:27:30.440 Contention, that's um, that's really close to that idea of conflict free right. 354 00:27:30.599 --> 00:27:36.440 UM. So so yeah, if you if you have two nodes that 355 00:27:36.440 --> 00:27:38.480 that need to kind of battle it out in order to figure out what the 356 00:27:38.519 --> 00:27:42.720 current state is, so you've got that Paxos kind of thing happening, then 357 00:27:42.799 --> 00:27:48.279 then you're going to waste a bunch of cycles in order to UM to resolve 358 00:27:48.640 --> 00:27:52.359 those those conflicts. Yea, but but yeah, if you UM, if 359 00:27:52.359 --> 00:27:56.880 you have a data structure that that proves that you will not have conflicts even 360 00:27:56.920 --> 00:28:02.319 if you are on just a mobile phone and you're disconnected from the from the 361 00:28:02.359 --> 00:28:07.359 network for you know, any period of time when you finally do reconnect, 362 00:28:07.640 --> 00:28:11.640 there will be no conflicts. Then you don't have to waste time resolve in 363 00:28:11.680 --> 00:28:15.440 those conflicts. And UM, while you're disconnected, the user is interacting directly 364 00:28:15.480 --> 00:28:19.400 with that device. They're not waiting on any you know, connection to the 365 00:28:19.440 --> 00:28:25.319 network. So UM. So yeah, it gives you some some performance benefits 366 00:28:25.799 --> 00:28:30.440 UM you know as well as that that scalability. Is this product and open 367 00:28:30.480 --> 00:28:33.720 source product? Does it work on all dot net platforms? What's the story 368 00:28:33.759 --> 00:28:37.319 there? Yeah, this is this is an open source project. Um UH. 369 00:28:37.440 --> 00:28:42.319 It is is currently uh primarily in JavaScript. UM Jenaga dot net is 370 00:28:42.359 --> 00:28:49.759 the the newest incantation of it UM but Jaga JS is UM is for for 371 00:28:49.799 --> 00:28:53.920 the client and for the server. So there's uh UM there's a UM you 372 00:28:53.960 --> 00:28:59.680 know MPM installed Jenaga and there's a human installed Janaga dash server. UM. 373 00:28:59.720 --> 00:29:04.160 So when you when you running on the server, UM that's to be run 374 00:29:04.319 --> 00:29:11.960 as an express uh node application and it gives you some some endpoints. Then 375 00:29:11.000 --> 00:29:18.440 that give you access to its um its internal replicator and then you install Jenaga 376 00:29:18.599 --> 00:29:26.240 as as a client in your React application or React native and um UH and 377 00:29:26.279 --> 00:29:32.519 then that connects to that replicator and UM and genagages on the client can also 378 00:29:33.119 --> 00:29:41.920 UM use UM use the web dB or index dB for um UH for the 379 00:29:41.920 --> 00:29:45.640 web in order to support progressive web aps, so you can go offline with 380 00:29:45.720 --> 00:29:48.920 your PWA. I was, I was very I did some work with the 381 00:29:49.000 --> 00:29:55.400 nextb Uh last year and I was really impressed, you know. But I 382 00:29:55.440 --> 00:30:00.319 was using a wrapper for Blazer around it, which turned out to be great, 383 00:30:00.720 --> 00:30:03.519 because man, that's scary stuff. If you're going to deal with it 384 00:30:03.599 --> 00:30:07.000 in JavaScript, more power to you, my friend. That's yeah, it's 385 00:30:07.039 --> 00:30:14.000 so scary code. Yeah, yeah, Well I'm aiming toward that, uh, 386 00:30:14.319 --> 00:30:17.920 that place where as a developer you just have to write the specification, 387 00:30:18.119 --> 00:30:22.480 yeah, and then let them let the language, let the platform figure out 388 00:30:22.519 --> 00:30:26.799 the h the behavior. So. Um. So when you're doing a lot 389 00:30:26.799 --> 00:30:30.920 of disconnect to mobile apps, you're thinking about, oh, I'm in you 390 00:30:30.960 --> 00:30:34.799 know, I'm in connected mode. I'm in disconnected mode. I have code 391 00:30:34.839 --> 00:30:37.839 that writes to the local database. I have code that talks to the API. 392 00:30:38.240 --> 00:30:41.720 You know, I have code that that synchronizes things together. And so 393 00:30:41.799 --> 00:30:45.039 you're you're doing a lot of that bookkeeping yourself as a programmer, right. 394 00:30:45.160 --> 00:30:48.920 Um. But but in Janaga, when I'm when I'm going for is a 395 00:30:48.960 --> 00:30:52.920 place where you can say, yeah, here's the fact the user just um 396 00:30:53.200 --> 00:30:57.000 just did this thing. You know, they entered some stuff into a form 397 00:30:57.000 --> 00:31:00.960 impress safe award that fact just just a jobascript object. Yeah. And then 398 00:31:02.400 --> 00:31:07.240 um, here's a specification which says, um, you look for facts of 399 00:31:07.240 --> 00:31:11.960 this particular shape where these other related facts exist or do not exist. Yeah, 400 00:31:12.039 --> 00:31:17.680 so you write this this pretty much this mathematical specification for you know what 401 00:31:17.720 --> 00:31:21.200 it is you're looking for, and then give me a projection. Turn that 402 00:31:21.319 --> 00:31:25.079 into a thing that I could just bind into the screen. Yeah, and 403 00:31:25.119 --> 00:31:30.039 then let the run time figure out how to save that to local store, 404 00:31:30.119 --> 00:31:36.000 how to talk to the server, how to synchronize those those data sets. 405 00:31:36.039 --> 00:31:37.960 Awesome, And that's pretty cool. And I'm gonna interrupt for one moment for 406 00:31:38.039 --> 00:31:45.519 this very important message, and we're back. It's done at rocks A Richard 407 00:31:45.559 --> 00:31:48.279 Campbell. That's Carl Franklin. Hey, hey, hey, talking to our 408 00:31:48.319 --> 00:31:52.119 friend Michael Perry, late of the Tablet show, very late. I think 409 00:31:52.119 --> 00:31:56.240 we did the last tablet show in twenty fourteen. Website doesn't even come up 410 00:31:56.240 --> 00:31:57.839 anymore. And the Melvin the website has come up. Who knows that maybe 411 00:31:57.920 --> 00:32:00.599 we can at the moment, Yeah, turned his statical. It's always archive 412 00:32:00.680 --> 00:32:04.880 dot org. Maybe I'll pull it, pull it up that way, and 413 00:32:04.880 --> 00:32:07.559 and it's still apparently on on where all the podcasts are. So, yeah, 414 00:32:07.599 --> 00:32:12.319 the podcast engines are still got it. Um. But we're talking a 415 00:32:12.319 --> 00:32:17.240 bit about immutable architectures and I sort of get this. Where does CQRS come 416 00:32:17.279 --> 00:32:22.160 into play? And I guess I'll define the acronym command query responsibility segregation because 417 00:32:22.160 --> 00:32:29.279 now that you know the words, it makes way more sense command query responsibility 418 00:32:29.279 --> 00:32:31.359 segregation, I can. I can boil it down and tell me how. 419 00:32:31.839 --> 00:32:37.359 And this is purely from memory. Basically, you have one data source for 420 00:32:37.440 --> 00:32:39.839 quarrying and another data source for writing. Is that it? That's one way 421 00:32:39.839 --> 00:32:44.400 of implementing it. Yeah, yeah, it's not necessarily that, um okay 422 00:32:44.440 --> 00:32:50.480 as um yeah, Oudi Dahan and and Greg Young would would point out not 423 00:32:50.480 --> 00:32:52.960 necessarily yeah, sure, but yeah, that's that's one that's general. Just 424 00:32:53.200 --> 00:32:58.920 that I learned that when you write to a data a data source that has 425 00:32:59.079 --> 00:33:04.359 eventual consists stancy to the one to the second data base or data source that 426 00:33:04.519 --> 00:33:07.319 we acquery from. Right, Yeah, that that is the most common way 427 00:33:07.319 --> 00:33:08.920 of doing things, and it makes a lot of sense. Like you were 428 00:33:08.920 --> 00:33:15.720 just saying, you wouldn't want to run reports off of an immutable history of 429 00:33:16.079 --> 00:33:20.839 records. Um, that's not what that's for um, so use something else 430 00:33:20.880 --> 00:33:23.279 for that. And that's perpectly what cr QRS means to me is that, 431 00:33:23.720 --> 00:33:28.359 um, you're going to have something that's really good for those those reports. 432 00:33:28.440 --> 00:33:32.359 For that read side, that's your projections. Yeah, so run your reads 433 00:33:32.359 --> 00:33:37.319 from your projections, um, and then your rights. You're sending those into 434 00:33:37.519 --> 00:33:42.079 some transactional system. And if that transactional system happens to be a directed a 435 00:33:42.160 --> 00:33:47.160 cyclograph of them middle records, you're golden. Yeah, I hear you got 436 00:33:47.200 --> 00:33:55.880 events sourcing on your events, So I got this to a subliminal events sourcing 437 00:33:55.920 --> 00:34:04.000 every other words in chewing events starcing. But I do appreciate the idea of 438 00:34:04.200 --> 00:34:08.000 optimize the ingress path and optimize the outgress path separately. Right right, that 439 00:34:08.039 --> 00:34:13.960 there's an ingress path for orders to be entered, and then there is that 440 00:34:14.079 --> 00:34:17.840 One of the output paths is fulfillment, but another one it can be is 441 00:34:17.880 --> 00:34:22.360 reporting. They don't have to be Why do one thing everything in one place 442 00:34:22.440 --> 00:34:25.840 and basically have suboptimal versions of all of it? Right right? Exactly? 443 00:34:28.199 --> 00:34:31.119 Yes? Yes, And now imagine that you could just write a specification what 444 00:34:31.280 --> 00:34:37.159 does your reporting database look like? Yeah? And then computer you figure out. 445 00:34:37.239 --> 00:34:40.480 Okay, whenever this event happens, go update that table. Right, 446 00:34:40.639 --> 00:34:45.840 that's computation, that's machines. Yea, you could solve that. But I 447 00:34:45.840 --> 00:34:50.519 mean this is where you get into that sort of relationship mapping thing. It 448 00:34:50.599 --> 00:34:52.760 says, this is what the incoming stream looks like. Maybe it's blobs, 449 00:34:53.199 --> 00:34:57.199 you know, it doesn't really matter, whatever it comes to, and it 450 00:34:57.320 --> 00:35:00.719 maps it out asynchronously the transaction. It has already been received, but a 451 00:35:00.880 --> 00:35:05.960 syncreitly now distribute it to various sources that care for it. Yeah. Yeah, 452 00:35:06.079 --> 00:35:07.239 oh and you've got to have a queue in there somewhere, or at 453 00:35:07.280 --> 00:35:12.199 least at least one. Yeah, that's okay. Wow, that that is 454 00:35:12.519 --> 00:35:15.280 UM. So I want to kind of kind of kind of tie this back 455 00:35:15.280 --> 00:35:19.679 to UM what we were just talking about with event sourcing. UM I do 456 00:35:19.800 --> 00:35:25.639 I do uh uh I do offer an alternative to event sourcing as a different 457 00:35:27.559 --> 00:35:32.199 immutable architecture that I call historical modeling UM. Whereas event sourcing is this, 458 00:35:32.760 --> 00:35:39.760 UM is this at least piece wise uh linear set of of events a historical 459 00:35:39.800 --> 00:35:45.320 model UM. They they don't have to be linear, they don't have to 460 00:35:45.519 --> 00:35:50.320 have occurred in a in a specific order. Um, it's not tied to 461 00:35:50.360 --> 00:35:52.719 the data per se, it's tied to them. Yeah yeah. Let me 462 00:35:52.800 --> 00:35:57.960 let me see if I can give a practical example. So, um, 463 00:35:58.039 --> 00:36:00.119 so yeah, you you placed an order, say yeah, you know as 464 00:36:00.119 --> 00:36:04.800 a customer. Um, and then what's the next thing that's probably going to 465 00:36:04.840 --> 00:36:07.519 happen. Well, the you know, the shipping department is going to pick 466 00:36:07.559 --> 00:36:12.559 that up and they're going to create a picklist. But also the accounting department's 467 00:36:12.559 --> 00:36:14.639 going to pick that up and they're going to create an invoice. Yep. 468 00:36:14.800 --> 00:36:20.000 So the picklist and the invoice are both historical facts. There there happened, 469 00:36:20.119 --> 00:36:23.960 They happened. There's their decisions that somebody made based on that order. So 470 00:36:24.119 --> 00:36:28.559 if you model that as a tree, you'll see here's the order at the 471 00:36:28.599 --> 00:36:34.119 top, and then the picklist and the invoice are two leaves of that tree, 472 00:36:34.199 --> 00:36:37.119 both pointing up to that common route. So it makes a little triangle. 473 00:36:37.199 --> 00:36:40.440 Yeah. Yeah, I would argue the picklist is fulfillment. Shipping is 474 00:36:40.440 --> 00:36:45.480 another task. Again. You know that you end up with this series of 475 00:36:45.679 --> 00:36:50.840 artifacts related to the order, and they're all done to different people. Sometimes 476 00:36:50.880 --> 00:36:53.679 they're sequential. You need to be picked before you can ship and in theory, 477 00:36:53.760 --> 00:36:59.760 you shouldn't invoice until you ship. Yeah, but the tree architecture sounds 478 00:36:59.800 --> 00:37:02.519 like handles that. However, you want to branch it. Yeah, yeah, 479 00:37:02.559 --> 00:37:07.760 exactly. Yeah, so shipment is another historical fact that that points back 480 00:37:07.800 --> 00:37:12.320 to the pick list. The shipment doesn't care about the invoice, no, 481 00:37:12.400 --> 00:37:15.719 so it's just pointing up to the pick list. Yeah, there's a there's 482 00:37:15.719 --> 00:37:19.840 an accounts receivable, which is actually just a report that you run from invoices. 483 00:37:19.880 --> 00:37:22.159 So their accounts receivable itself isn't not a new factor, but the payment 484 00:37:22.599 --> 00:37:27.480 is another another element is another fact. Yeah, and that points to the 485 00:37:27.519 --> 00:37:31.559 invoice, but the payment doesn't point to the shipment or to the pick list. 486 00:37:31.760 --> 00:37:37.800 So you've got this this this tree, this graph that branches m and 487 00:37:37.880 --> 00:37:44.239 now do now do a partial return or a warranty replacement? Like and you 488 00:37:44.239 --> 00:37:46.199 can tell the architects in the room because you get all really excited, good 489 00:37:46.239 --> 00:37:52.360 white boards drawing for you. Yeah, but you're looking for those dependencies and 490 00:37:52.519 --> 00:37:57.760 what they're related to and where we can make them execute independently like this. 491 00:37:57.840 --> 00:38:02.199 You're also unique units of work for development too. Yeah. Yeah, this 492 00:38:02.320 --> 00:38:05.960 is how it's always that question of how do I get six people to work 493 00:38:06.000 --> 00:38:08.199 on this. It's like, well, because you peel out the one piece, 494 00:38:08.239 --> 00:38:12.400 the payment engine, and that goes to one person, maybe two. 495 00:38:12.639 --> 00:38:15.079 If you're doing a little pair of programming, you want two sets of eyes 496 00:38:15.159 --> 00:38:17.639 on things, and then others are on other pieces. Like you have these, 497 00:38:19.440 --> 00:38:22.800 you know, areas of concern that have discrete interfaces on them that allow 498 00:38:22.880 --> 00:38:28.320 you to paralyze development, right, exactly. Yeah, And so the same 499 00:38:28.320 --> 00:38:31.079 reason that I shipped two copies of Mythical Man month to every manager so they 500 00:38:31.079 --> 00:38:36.320 could read it twice as fast. And I'm going to read Michael's mind here. 501 00:38:36.320 --> 00:38:38.320 He's saying what I would do is I would write the engine and then 502 00:38:38.440 --> 00:38:42.960 have one guy right the spec for everything, and then the engine does it 503 00:38:43.039 --> 00:38:46.159 all right, yes, yes, and that's what we want. Yeah. 504 00:38:46.159 --> 00:38:50.199 And the person who writes the engine doesn't even know about your problem, doesn't 505 00:38:50.320 --> 00:38:53.679 care, and he's long gone No, he's got a problem factory somewhere. 506 00:38:53.920 --> 00:39:00.920 Exactly. Oh, one of my favorite jokes. All right, these are 507 00:39:00.960 --> 00:39:06.239 a whole bunch of insider architect jokes. I'm pretty sure we're making fun of 508 00:39:06.239 --> 00:39:08.840 ourselves. I had a problem, so I use Java. Now I have 509 00:39:08.880 --> 00:39:13.639 a problem factory. It's an old joke, but a good one, and 510 00:39:13.639 --> 00:39:19.679 you have to say it's slower than that because you know Joba. Yeah right, 511 00:39:21.400 --> 00:39:23.000 all right, I'm not shouldn't make fun of Jab. Those guys do 512 00:39:23.079 --> 00:39:27.239 good work and they're more like us than different. That's true. It's not 513 00:39:27.320 --> 00:39:29.440 fair at all, and there no reason to be mean to them. They 514 00:39:29.440 --> 00:39:38.159 have oracle for that. Man. How much time do you spend doing architecture 515 00:39:38.159 --> 00:39:43.079 that, Michael, I mean you work for an agile practice group, right, 516 00:39:43.719 --> 00:39:45.920 yeah, yeah, I work for Improving and yeah, so we we 517 00:39:45.960 --> 00:39:53.960 offer consulting agile training, and so my role at Improving is to help help 518 00:39:54.000 --> 00:40:00.000 other improvers grow their careers and also, by the way, bill clients. 519 00:40:00.079 --> 00:40:06.320 So so yeah, I'm um, yeah, I'm often running a team at 520 00:40:06.320 --> 00:40:09.920 a client, So in addition to helping to to grow that team, I'm 521 00:40:09.960 --> 00:40:15.760 in charge of the architecture for the project as well as often doing you know 522 00:40:15.800 --> 00:40:23.320 them you know, technical lead role, right because I mean presenting a directed 523 00:40:23.440 --> 00:40:29.000 bicyclic graph to the average developer, they're they're like, where do I log 524 00:40:29.039 --> 00:40:32.800 in? Like, it's it's not a product, right, it's a thinking 525 00:40:32.880 --> 00:40:37.760 model. And then you get into questions about well, how do I implement 526 00:40:37.800 --> 00:40:43.559 this? Like, is there a library that will drive me towards a Dagum? 527 00:40:43.880 --> 00:40:46.880 I don't start people there. Um okay, yeah, so I start 528 00:40:46.880 --> 00:40:52.599 people first with analysis. Let's use a director bicyclic graph in order to analyze 529 00:40:52.639 --> 00:40:59.119 the problem, and that uncovers all sorts of edge cases, but then also 530 00:40:59.159 --> 00:41:01.679 gives you a way to document them. So you say, okay, you 531 00:41:01.760 --> 00:41:07.239 know, like the the the returns that you were just talking about. Yeah, 532 00:41:07.280 --> 00:41:10.719 So the breakdown and giggles we just had was actually working through the graph 533 00:41:10.840 --> 00:41:15.119 of a retail workflow or an e commerce workflow, right, I mean I've 534 00:41:15.119 --> 00:41:19.320 done so many times I don't even laugh about it anymore. Right, this 535 00:41:19.440 --> 00:41:21.960 is just like it's the number of times you figured out, are we going 536 00:41:22.000 --> 00:41:24.320 to do back ordering? How do we do returns? You know, do 537 00:41:24.360 --> 00:41:27.920 we do unify where you can deliver back to the store? Like yeah, 538 00:41:27.960 --> 00:41:34.360 and and just drawing out those diagrams, like I think you forget how weird 539 00:41:34.440 --> 00:41:37.199 it is. Yeah, yeah to think about business processes that way. Yeah, 540 00:41:37.239 --> 00:41:42.840 And a lot of times people will draw those diagrams as as flu charts 541 00:41:42.960 --> 00:41:47.960 or as state transition diagrams or you know, the more modern equivalent to draw 542 00:41:49.000 --> 00:41:52.079 those ash as a sequence of events. You know, do some events storming, 543 00:41:52.360 --> 00:41:58.639 right. Um. But the the the diagram that I that I propose 544 00:41:59.199 --> 00:42:05.679 is one where you've got an ellipse that represents one historical fact, one decision, 545 00:42:05.800 --> 00:42:09.159 right, and then it's got arrows pointing up to the predecessors, those 546 00:42:09.199 --> 00:42:14.000 decisions that had to have come before, right. Um. And so now 547 00:42:14.039 --> 00:42:17.519 you can walk this tree or this graph really in um, in any order 548 00:42:17.559 --> 00:42:22.199 as long as it's from the from the past to the future, from the 549 00:42:22.239 --> 00:42:25.599 top down. Um. So you have to follow those arrows backwards, I 550 00:42:25.679 --> 00:42:30.599 like from arrows backwards. But uh, but but yeah you can. You 551 00:42:30.599 --> 00:42:34.119 can. You can take any of those paths at any time, and you 552 00:42:34.119 --> 00:42:39.719 can describe all sorts of different scenarios with that same graph. So it ends 553 00:42:39.800 --> 00:42:45.000 up being a lot cleaner, a lot easier to understand than a flow chart 554 00:42:45.239 --> 00:42:50.039 or a or state machine that does the same thing. Yeah, I do 555 00:42:50.079 --> 00:42:53.960 appreciate that it's more representative of the problem space ultimately to say, it's sort 556 00:42:53.960 --> 00:42:59.320 of really organizing by artifact, Yeah, exactly. And so then once once 557 00:42:59.360 --> 00:43:04.199 I've got people thinking in terms of a director day cyclic graph to analyze the 558 00:43:04.239 --> 00:43:07.039 problem. Then we can start talking about how do you implement based on right, 559 00:43:07.599 --> 00:43:12.639 And even for that, I don't jump to hey, let's use Janaga 560 00:43:13.320 --> 00:43:17.360 Instead, I say, all right, you're used to relational databases. Relational 561 00:43:17.440 --> 00:43:22.360 databases have foreign keys. A foreign key is a reference to another record. 562 00:43:22.559 --> 00:43:30.239 So what if every record was an immutable historical fact and those those foreign keys 563 00:43:30.320 --> 00:43:35.480 were the coiners to your predecessors. Let's actually build a database like that. 564 00:43:36.440 --> 00:43:39.679 I've I've done a number of systems that way, and it's it's really really 565 00:43:39.719 --> 00:43:45.320 powerful. What about structures and data like like I'm thinking of lists of objects 566 00:43:45.320 --> 00:43:50.639 of things. If you already use immutable disimmutable architecture where you have records, 567 00:43:50.840 --> 00:43:55.760 now you've got duplicate records that you know, no, this is the current 568 00:43:55.760 --> 00:44:00.719 one, and these are the historical ones that could get Harry, couldn't it. 569 00:44:00.960 --> 00:44:04.960 Oh yeah, that's that's that's a really fun problem. Um. So 570 00:44:05.239 --> 00:44:08.199 yeah, there's a pattern that I that I go through in the book called 571 00:44:08.239 --> 00:44:13.400 the mutable property pattern. Wait, you just said immutable. You called this 572 00:44:13.440 --> 00:44:19.039 the immutable immutable property. What's he broke his own rules? Yeah, so 573 00:44:19.239 --> 00:44:25.400 this is a way all the other farmers on tattooing think of you because yeah, 574 00:44:25.639 --> 00:44:30.079 this isn't right, but the um but yeah, the idea is that 575 00:44:30.119 --> 00:44:36.159 you were going to simulate mutability using immutable records and um. And so the 576 00:44:36.199 --> 00:44:40.519 way that I that I simulate a mutable property is that I've got a historical 577 00:44:40.519 --> 00:44:45.440 fact that says the value this property is this value, and the prior value, 578 00:44:45.440 --> 00:44:49.920 the one that I just replaced, is that one. So it's the 579 00:44:50.039 --> 00:44:54.840 predecessor. The pointer to the other fact is the previous version of that of 580 00:44:54.840 --> 00:44:59.800 that property. Now, what's really cool about this is if you think about 581 00:44:59.800 --> 00:45:01.679 this not in terms of a sequence, but in terms of a graph, 582 00:45:01.800 --> 00:45:07.960 you can have concurrent changes to a property. You're can have somebody and you 583 00:45:07.039 --> 00:45:13.079 can have on their cell phone somebody else on the website, and you both 584 00:45:13.159 --> 00:45:17.800 create these facts that point back to the same prior version. Right, and 585 00:45:17.840 --> 00:45:22.719 so you've created a tree. You're okay with a tree. Then that two 586 00:45:22.039 --> 00:45:25.519 facts could be pointing back to the same historical facts. Yes, yes, 587 00:45:25.639 --> 00:45:31.400 exactly, you are crazy, mister Perry. But but yeah you're used to 588 00:45:31.440 --> 00:45:39.039 that as well. In get I'm just curious. No, all right, 589 00:45:39.159 --> 00:45:45.079 So this is how strings work, isn't it inherently how strings are immutable objects 590 00:45:45.119 --> 00:45:49.320 that when you say, you know, my string variable equals this and then 591 00:45:49.880 --> 00:45:54.480 equals this plus that, you're actually creating a new string that from this plus 592 00:45:54.519 --> 00:46:00.360 that, and the string that just had this in it is gone. It's 593 00:46:00.440 --> 00:46:05.119 it's marked for death. That's it's unusable memory. Now freed memory. Yeah, 594 00:46:05.159 --> 00:46:07.679 so it's well, it's not immediately freed, it will be it is. 595 00:46:07.719 --> 00:46:09.639 It is immutable, so you've you've got that part. The thing that 596 00:46:09.880 --> 00:46:15.039 strings don't do is keep track of what was the previous string in this variable, 597 00:46:15.159 --> 00:46:17.280 right, Yeah, you can't undo a string for example. Yeah, 598 00:46:17.360 --> 00:46:22.440 but but string dot undo. Yeah, taking it back to to get It's 599 00:46:22.480 --> 00:46:27.320 perfectly fine to have two different commits that point back to the previous commit. 600 00:46:27.400 --> 00:46:30.559 You've just cut a branch. Well, yeah, all perfectly fine until you 601 00:46:30.559 --> 00:46:36.159 you try and merge and nobody's fine. Or you try to do a link 602 00:46:36.239 --> 00:46:39.760 query to to find some records in the in your record list. Uh huh, 603 00:46:39.920 --> 00:46:43.679 yeah, okay, let's let's put a pin in the link query one. 604 00:46:43.840 --> 00:46:46.400 Okay, yes, that's really cool. Um, but but merge, 605 00:46:46.440 --> 00:46:50.039 I do want to I would do want to talk about that. So in 606 00:46:50.039 --> 00:46:54.039 in critt is one of the One of those operations that this data structure needs 607 00:46:54.039 --> 00:46:59.199 to perform is a merge operation, but it's not the same as a get 608 00:46:59.320 --> 00:47:06.840 merge. Get is a cr DT. So if you were to if you 609 00:47:06.880 --> 00:47:10.559 were to fetch from a remote, now you're performing a merge. You're taking 610 00:47:10.599 --> 00:47:15.920 information in that remote and you're merging that information into your own directed a cyclic 611 00:47:15.960 --> 00:47:20.800 graph on your repository. Actually performing a get merge creates a new commit, 612 00:47:21.280 --> 00:47:25.360 So that is an actual change, that's an update, that's creating a new 613 00:47:25.440 --> 00:47:30.360 historical record. And now that you've created that, you can push, which 614 00:47:30.480 --> 00:47:35.519 is a merge in the opposite direction. So so yeah, the thing that 615 00:47:35.519 --> 00:47:37.119 we call merge and get, which is so painful, it's actually not a 616 00:47:37.159 --> 00:47:42.079 merge. And the thing that we call emerge conflict in get is not a 617 00:47:42.199 --> 00:47:47.679 conflict in the term of in the CRDT world, because as a CRDT it 618 00:47:47.679 --> 00:47:53.320 should be conflict free, right right. What's actually happening is the interpretation of 619 00:47:53.840 --> 00:48:00.679 what this history means now has has been called into question because you've got concurrent 620 00:48:00.800 --> 00:48:06.480 edits, And that's exactly what's happening when you've got these mutable properties that two 621 00:48:06.519 --> 00:48:09.400 people change at the same time. Now you're calling into question what does that 622 00:48:09.599 --> 00:48:15.519 mean? And the data structure itself, it's not in conflict. It's got 623 00:48:15.199 --> 00:48:20.039 a graph that has two leaves on it. That's perfectly fine. And now 624 00:48:20.119 --> 00:48:22.440 your interpretation of it is where you say, oh, was it this phone 625 00:48:22.480 --> 00:48:25.800 number or that phone number? Which one is it? And then the way 626 00:48:25.840 --> 00:48:29.760 I like to do that is to allow a human, just like can Get, 627 00:48:29.960 --> 00:48:35.119 to resolve that conflict, to make the decision which is the correct phone 628 00:48:35.199 --> 00:48:39.960 number, and then create a brand new historical fact that points both of them, 629 00:48:40.159 --> 00:48:44.199 just like can Get when you do emerge commit it points to both of 630 00:48:44.239 --> 00:48:45.920 its parents. So it was looking at Get for you. The sort of 631 00:48:45.960 --> 00:48:50.480 impetus of this pattern that you're describing. I mean, you seem to be 632 00:48:50.480 --> 00:48:52.679 referring to Get a lot or was it like, oh, Get does this 633 00:48:52.760 --> 00:48:57.960 thing that's in my brain? How fortuitous? Yeah, it was. It 634 00:48:58.039 --> 00:49:00.679 was a little bit more of the latter, because I first had this idea 635 00:49:00.840 --> 00:49:07.440 of um, of you kind of paying attention to the history rather than the 636 00:49:07.480 --> 00:49:14.480 current state around two thousand and one, and I wasn't um yeah, I 637 00:49:14.559 --> 00:49:17.239 wasn't familiar with it. If it was around at that time, Um No, 638 00:49:17.320 --> 00:49:22.360 I don't think so. Yeah, but but yeah, then then I 639 00:49:22.440 --> 00:49:24.440 kind of started to evolve this and then I saw, oh, there's event 640 00:49:24.480 --> 00:49:29.639 sourcing. Oh, that's that's also paying attention to the history and not the 641 00:49:29.679 --> 00:49:32.960 current state, but in a different way. Interesting that that feels about. 642 00:49:34.000 --> 00:49:37.320 Right, Oh, here's a get Oh that's doing this thing in a much 643 00:49:37.360 --> 00:49:39.800 more familiar way, but just for source code, whereas I want to do 644 00:49:39.840 --> 00:49:44.960 this for every vacations in general. Yeah. Oh, that's so a lot 645 00:49:45.000 --> 00:49:47.000 of things. It all kind of felt familiar, well all happening at the 646 00:49:47.039 --> 00:49:50.679 same time. All right, well that's wow, that's really cool. So 647 00:49:51.280 --> 00:49:53.480 I've just one more question before we go. When you go out on a 648 00:49:53.480 --> 00:49:55.599 clear night and you look up at the sky, do you see two full 649 00:49:55.599 --> 00:50:00.840 moons? Uncle? And this are too? You know it's got a bad 650 00:50:00.880 --> 00:50:07.400 motivator. No, seriously, this is mind blowing stuff. And just to 651 00:50:07.599 --> 00:50:12.039 be able to think this way and apply it to common things that you're using 652 00:50:12.119 --> 00:50:15.840 everyday life and now could it how could it make things better? Yeah? 653 00:50:15.920 --> 00:50:19.360 I love that. Yeah, it's it is. It is amazing when when 654 00:50:19.400 --> 00:50:23.719 I'm able to bring a development team along with me and we use this as 655 00:50:23.840 --> 00:50:29.559 the way of thinking about a product about the way that we developed the product. 656 00:50:30.159 --> 00:50:32.639 It really comes up with something, you know, much better than we 657 00:50:32.719 --> 00:50:35.599 could have done that at it. What's the name of the book again? 658 00:50:35.760 --> 00:50:38.440 The book is called The Art of Immutable Architecture Excellent and you can get it 659 00:50:38.440 --> 00:50:42.159 wherever fined books are sold. I take it. Yes, you can go 660 00:50:42.159 --> 00:50:45.119 to immutable Architecture dot com. That will give you a link directly to it. 661 00:50:45.239 --> 00:50:46.719 Do you have an audible version? Um, I do not yet have 662 00:50:46.760 --> 00:50:51.239 an audible version, but yeah, it would be a great idea. Well, 663 00:50:51.320 --> 00:50:58.800 don't ask me to read it, because I love all nobody expects all 664 00:50:58.800 --> 00:51:04.519 the w T apps. I will read it however. So yeah, this 665 00:51:04.599 --> 00:51:07.480 is great stuff. Michael. Thanks, thanks very much for being with us 666 00:51:07.559 --> 00:51:09.000 today. Thanks, thanks, thank you. All right, We'll see you 667 00:51:09.079 --> 00:51:34.639 next time on dot net rocks. Dot net Rocks is brought to you by 668 00:51:34.719 --> 00:51:38.960 Franklin's Net and produced by Pop Studios, a full service audio, video and 669 00:51:39.039 --> 00:51:44.920 post production facility located physically in New London, Connecticut, and of course in 670 00:51:44.960 --> 00:51:51.239 the cloud online at pwop dot com. Visit our website at dt n et 671 00:51:51.599 --> 00:51:55.440 r o c ks dot com for RSS feeds, downloads, mobile apps, 672 00:51:55.599 --> 00:52:00.559 comments, and access to the full archives going back to show number one, 673 00:52:00.119 --> 00:52:04.920 recorded in September two thousand and two. And make sure you check out our 674 00:52:04.960 --> 00:52:08.239 sponsors. They keep us in business. Now go write some code. See 675 00:52:08.239 --> 00:52:22.079 you next time you got a band,