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,