How'd you like to listen to dot net rocks with no ads? Easy? Become a patron For just five dollars a month you get access to a private RSS feed where all the shows have no ADS. Twenty dollars a month will get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot net rocks dot com. Hey Carlin Richard here. As you may have heard, NDC is back offering their incredible in person conferences around the world, and we'd like to tell you about them. NDC Oslow will
be made twenty first through the twenty fifth. Go to NDC Oslo dot com to register. NDC Copenhagen is happening August twenty seventh through the thirty first. The early bird discount for NDC Copenhagen ends June second. Go to NDC Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the twentieth. The early bird discount for dc Porto ends July twenty first. Go to EDDC Porto dot column to register and check out the full lineup of conferences at
NDC conferences dot com. Http timeouts Database deadlocks in software, it's not a matter of if things fail, it's a matter of when one mishap like this and some valuable data is lost forever. And these failures occur all the time, but it doesn't have to be this way. Introducing end service bus, the ultimate tool to build robust and reliable systems that can handle failures gracefully,
maintain high availability, and scale to meet growing demand. For more than fifteen years, end service bus has been trusted to run mission critical systems that must not go down or lose any data ever. And now you can try it for yourself. End service bus integrates seamlessly with your dot net applications and can be hosted on premises or in the cloud. Say goodbye to loss data and system failures, and hello to a better, more reliable way of building distributed
systems. Try end service bus today by heading over to go dot particular, dot net slash dot net rocks and start building better systems with asynchronous messaging using end service bus. Hey, guess what it's dot net and rocks. I'm Carl Franklin and I'm Richard Campbell. We're getting all of these shows done so that we can go travel for a bit going on adventures, going on adventures. We'll do more shows while we're adventuring too, And we're gonna be at
Techarama in Belgium. And I believe you're going to Dot Net Developer Days twenty twenty three in Poland, right, yeah, in Warsaw Warsaw. I'll be there, but I think I have the opening keynote. Actually, yeah, that's cool. I don't know for sure, but it's possible I be there, But if you want to check it out and you're anywhere near Poland in October, it's net dot Developer Days dot PL. It's a it's a great conference. I went there a couple of years ago and I had a great
time. Yeah, we had a ton of fun there. Yeah. Okay, anyway, let's get right to the meat of it with better no framework. All right, man, what do you got? All right? So this is a blog post by Eric Elliott March thirty first on medium dot com. This guy has written a pseudocode programming language. I almost said pseudacu.
A pseudo code programming language for large language models. And it's called pseudo lang sud O l A n G. See what he did there, Yeah, and so he's been using pseudocode to express ideas to large language models since GPT three. However, up until GPD four it didn't work extremely well. But then he's working on it, and I haven't used it. But there's a whole bunch of statistics and stuff in there, and he says, here's some commands and some modifiers and examples and it, and it looks good. I
don't know, it seems pretty complex. I mean, isn't English a pseudo language in the first place? You would thinks so, yes, But I guess it's somewhere between a programming language and natural language. But there I thought the whole idea of large language models was to use language, right, I think that's what you're saying, right. I don't know. I can't really judge it because I haven't really read through it. So I thought it was
interesting and came across my desk. And since you know, we're in the hype cycle of GPT large language models and all of that stuff, people are going to start dipping their toes in tools to make them more powerful, right, So somebody should check that out and get back to us and let us know how cool it is. All it's all explorations at this point, but interesting ones. It is certainly interesting. It was talking to us today Richard
grabbed a comment offer. Show eighteen o nine is one we did about microservices architecture with our friend Shawn Wildermouth. Step back in follow twenty twenty two, Bart Lenois said, Carl, Richard and Sean thanks a lot for the show. These days, you seem to be doing something wrong if you're not using microservices and Kubernetes. It's like everyone forgot about the kiss principle and they have
this battle with almost every client. There's nothing wrong with a well architect monolith or service already an architecture and deploying a handful of services on Azure, app service or functions as minutes of work with minimal skill required. Only a small percentage come to the point where they need full blown microservices architecture, and if you're googling for it, you're not one of them. Listen, Bart,
here's your solution. When the customer says I would like some Kubernetes please, you get us a bottle, put a big logo on it says Kubernetes, and you squirted on them. And then if you're really smart, you say no. And I got to remind everybody that the kiss principle is and I quote you gotta lose your mind in Detroit Rock City. But I really appreciate this comment from Bart just because it's like, listen, there's not one way
to solve every problem. And if you're determining a technology before you've argetted an application, you have are on the wrong path. Right like that, It's that's just a given. Let's look at the problem space first, then we can talk about what we build. So Bort, thank you so much for your comment, and a copy of music cobuy is on its way to you. And if you'd like a copy of music co buy, write a comment
on the website at dot net rocks dot com or on Facebook. We publish every show there and if I read your comment, I'll send you a copy of music cobuy. And you know, you can follow us on Twitter. That's all cool, but it would be really cool if you followed us on mastadon because that's where all the cool kids are these days. I'm at Carl Franklin at tech hub dot social, and I'm Rich Campbell at mast social and
send us to two we'd like to hear from you. And that brings us to our friend Michael Perry, who I was shocked that we haven't had him on dot net rocks, but we did have him on the tablet show back in the day. So I guess everything just ran together in my brain and I'm well, it's it's not like we don't see mcconferences all the time, all four times. He's part of the circle. But we were roommates. Embarrassingly, we never did this show for crying out loud an MVP summit.
Weren't we weren't we roommates? Yes, we were. We were roommates. Yeah, we didn't choose to be. It was just like, hey, I know you, so let me formally introduce Michael Perry. Software is math. Every class is a theorem, the compiler is the proof, and unit tests check our work. Michael Perry has built upon the works of mathematicians like Mark Shapiro, Pat helland and Leslie Lamport to develop a mathematical system for software
development. He has captured this system in a set of open source projects Jinga and assisticant. I love assistant. Yeah that was my daughter's name. What yeah, Yeah, Well, when my daughter Kayla, whenever she thought her name was assisticant. No, but whenever she would help her mother out at a at a show, then you know she would ask, Hey, can it come along and be your assisticant. Oh that's so cool, that's great. I love that. It's almost like something that goes in a squirt bottle
for Kubernetes. Isn't it a little assisticant? And yeah? Well anyway, great, great to have you on the show. And just your bio sort of sets the tone for what we're going to talk about here, doesn't it. This is really fascinating to me. Yeah. In fact, the other open spurs project is pronounced in Janaka. It's oh what did I say? Jenga yeah? Jinga yeah, yeah. Yeah. It's not the the tower of bricks that are going to fall down on you. It's it's much more
staple than that, ji Naga. So what is Janaga? Yeah? Janaga is a platform for UM for managing data in a in a distributed system UM. One of the great examples is in a mobile application. If you think about each mobile device being its own separate node within the within the network UM, then you can you can have your your data on your mobile device, interact with it as a user, and then it uh um, it kind of sinks up with the replicator, uh and you get that eventual consistency.
So yeah, Janaga is a way to to turn your micro services mobile applications, web applications into these uh, these small isolated nodes that eventually will reach agreement. It's interesting. And Assisticant is what. Yeah. Assisticant is a is an MVVM framework um that is based on the idea of dependency tracking. If you remember, you know, Steve Sanders Sanderson's old knockout, Yeah your
library. Yeah, that's uh, that's the same the same algorithm that it It figures out what depends about what, so that when something changes it it notifies the dependent Wow. And so you're talking large object models, then yeah, I tend to use assisticant for the the smaller focused like this is going to be a view model for just a single page, or even a composite view model with the you know, you know, a page that has a list in each one of those elements in the list is its own smaller view
model. That's what I tend to use assisticant for, not so much for the larger ones. So some m MVVM frameworks come with sort of communication tools of one kind or another, don't they. Yeah, yeah, yeah. A lot of times when you see MBVM, it's like, how do I implement I not if I reputy changed, And I'm like, oh, let's take a step back. Let's not try to implement the programming problem at hand,
but instead try to specify the desired behavior. Yeah. Sure, and then let the computer figure out how to how to give you that that desired behavior. Or we could just use Blazer It's true. Yeah, yeah, Blazer is a fantastic isn't it great? Just love it? All right, So we're talking about how does this incredible bio here that you know that you've built these this mathematical system for software development and I guess your two projects that
you talk about illustrate this. But um, how does that align with the idea of immutable architectures? Yeah? Yeah, So this is this kind of goes back to UM. If you look at those mathematicitions I mentioned their Mark Shapiro, that first one he and UH and his co author Nuna Pergucia basically published the very first c RDT specification. That's a conflict free replicated data type UM. This is a mathematical object that has some amazing properties in that it
will reach eventual consistency. So it will reach consistency as soon as all of the nodes have received all of the information eventual consistency. Because this doesn't come up often on dot net rocks, but this is the idea that I have object A with a state, and when that state changes, eventually Object B that is some sort of replicant of it is going to change, whether that's a database or whatever, eventually. Yeah, yeah, exactly. Yeah.
And and what's really exciting about that so that you might have heard of algorithms like paxos that are based on consensus. So so these different nodes have to collaborate with one another, They have to you know, chat back and forth in order to come to an agreement who's going to have the correct state. In the case of a c RTT, the way that the data structure works will guarantee that as soon as they all receive the same information, they are
in the same state. They don't have to go through this extra this extra checks and balances. Yeah, it's pretty cool stuff. That is cool. Yeah, Well, it's interesting to have the stuff's sort of solved models, right, Like they're exemplars or design patterns even of how you should build these kinds of problems, like you should not invent a new implementation of eventual consistency. Right. Yeah, it's very easy to be wrong. It's very difficult
to detect that you're wrong and it is a solved problem. Yeah, yeah, it's UM. It's very similar to what I was just saying about, write the specification and let the computer figure out the implementation. Computers are really good at computation. Yea. They can take an equation, they can solve it, they can give you the correct answer. You give a human that
same problem, you're not going to make mistakes. UM. But now if if the human approaches that problem but instead and writes a specification, now what they're doing is they're they're giving the computer the equation. They're saying, I want you to produce the system that does this. Um. You know, like you know, taking it back to cr dts UM. One of the one of the first c r dts that UM that the Mark Shapiro and No Prusia published was tree doc. This is a cr DT that UM that supports
collaborative editing of text documents. So, um, so, if you're familiar with Google Docs, Google docs doesn't actually use this algorithm, using something else called operational transforms, which are known to have defects. But if they had used tree doc then basically by specifying okay, these are the rules of the r DT computer, you come up with the implementation. Then by using the mathematics of crdts, it would be able to come up with a correct implementation
of collaborative text editor. Michael, did your interest in computers and maths sort of grow at the same rate or what? Was there a period in your life when you were all math and computers came out to that man, Yeah, I think I think they pretty much did grow at the same rate. That's cool, but yeahs, I've just always loved the mathematical side of software. Yeah, that we've seen it as applied math. That's a very unique place to come from for software developers, isn't it, because you know,
you get to experiment with both models at the same time. Yeah. Yeah, and you end up with some really surprising results too. You know, some things that that people don't expect to work, Like when I show people assisticant um it's like, well, yeah, it's it's a very simple idea. You write it um like a property getter, for example, write a
property getter UM. And if it's going to reach out and get values from other uh from other properties, then you know that it depends upon those So why not just have the computer watch while it's executing that and see what it does. And now you've just tracked your dependencies and so whenever those things change, this property has changed, um. And so it's like, well, yeah, that that makes sense. That follows logically one from from the next.
You've basically just told me a proof uh that that you're going to get the correct behavior out of a dependency tracking system. And then you actually, well then here's an implementation of it. Let's run it and it works, and it's like it's magic. It's like I just explain it to you. Very reliable math at that. Yeah. Of course, many of the original computer people were mathematicians. I mean, fundamentally we're still all using von Yuman
machines. And von Neuman was a mathematician. The question is if he wasn't born in a day where there was no computers, would it be an a computer scientist rather than a mathematician, Like you didn't. You didn't really have a choice but to be a mathematician and end up in computing. That was the path for that time, that era. Yeah, yeah, that's true.
And yeah, if i'd if i'd have been born, you know, you know, fifty years earlier, Yeah, I would have just been a pure mathematicians, you probably would have gone into maths, right, Like, that's kind of you don't really have a choice. It's like, if you like that purity of problem solving, that's pretty much the only place it lives. You know. When I was in college and taking a computer science course, the computer teacher said you kind of gotta love math to get into it.
And she couldn't have been more wrong. I mean, the right right brain programming ideas were blooming in the nineties, like and she was just out of punch. You know. It wasn't all Fortran and you know and calculus programming and stuff. It was you know, we were talking about business logic, and we were talking about language and all of these things that computers could do. So so I got into it from a rape brain. Obviously, music is like, you know, music and computers sort of grew in my
brain at the same time. And and you know, so it's fascinating to me to find a species from the other side of the world the left brain approach, um, because you know that that's completely opposite to my experience. So, and I don't know about the rest of the you know, people out here, but the hardcore engineers that right, operating systems and stuff and right, you know, serious stuff with computer science degrees, they're they're certainly
more into the maths. But guys like you obviously who thought about really carefully thought about how these mathematical mathematical models play out and software. Yeah, isn't this a wonderful industry, so much diversity. There's room for all types of thought. Absolutely, Yeah, and they they dressed different parts of the problem space. Like it's not like us is running out of work. There's lots
and lots to do. But yeah, the the idea that you, you know, you have to love math to be involved in computing is just no longer correct. Yeah, there are elements of computing that certainly well served by math. But look, there are good tree negotiation strategies. They're APIs now you don't need to write one. Oh, yeah, you're good I still think that in order to do just basic stuff, especially any kind of UI
kind of need to know a few a few things. He needs to know ratios, he needs to know, you know, algebra a little bit, but it's not it's about it yet, you know, maybe a little trigonometry. I was working on some connects stuff and I needed some trigg and that was mind blowing. Yeah, and I think that I think there's a difference between them. The subjects of math that we just talked about, the trigonometry and algebra and even some calculus. Um, but then there's also the mathematical
thinking, this logical way of thinking. So um to one thing, I like to say when people ask, well, do you have to be good at math in order to program? And no, No, math and programming they're completely different to operations. In math, you're taking symbols and you're you're manipulating these abstract concepts in order to come up with a solution, whereas in programming you're taking symbols and manipulating these abstract concepts in order to come up with
a solution. Comparing the different things, yeah, just the shape of the symbols. Well, and really, who's the compiler today exactly. That's the difference. Yeah. So I like to think, um, it's not that you have to be good at math in order to be a good programmers that if you're a good programmer, you're good at math. You just didn't realize it, right, Yeah. Yeah. If you learn the if your learn the rules of symbolic math, you'll find you're already thinking that way, right.
Yeah. So where's the immutable part come from? Too? Yeah? So, um so it turns out that's one of the um one of the best cr dts. Um is a directed a cyclic graph of immutable records. So one more time, CRDT, just one more time. The Yeah yeah, CRT is a conflict free replicated data type. Okay. Um So, so by a data type we mean a data structure plus operations. Um So,
just like a linklest the data structure, if you will. But it's also got some operations and so that pair, that combination makes it a data type. That's ok, it's useful. Um. So, a conflict free replicated data type is a data type some structure and some operations that live on different replicas, different different nodes. Um. And it's conflict free because as you perform those operations, you will never get this, uh, this cr DT to be in a state of conflict on two different nodes. In other
words, no dependencies. It's it's it's it's pretty cool. Um. We can actually tie this right back to the best implementation of an immutable cr DT that just about everybody listening to the show should be familiar with, and that is GET. Okay, In GET, you you make a change, you you create a commit. A commit is an immutable record of the change that you just made, right, and part of that record is who made it
when, what was the commit comment? You know, where the contents of the commit, but also what is the identity of the prior commit um? And then GET will take all that together, put that into a data structure, compute the SHAW to BT six hash of it, and say, okay, that's the identity of this commit. Right now, you create another one, okay, collects all the information, and then what is the identity of
the previous one? What's the previous shot? I got it? And so by creating that that reference from one record back to the previous one, you're creating a directed a cyclic graph. So it's directed, it's always pointing back to the past. Here's the prior commit, here's the prior commit. UM. And it's a cyclic because there's no way for you to make a commit that will then refer to something that comes loops back around and points back to
itself. Yeah, so sort of the journal of pattern. Yeah there if you will, Yeah, yeah, exactly, yeah and and um so so I would I would call GET an example of an immutable architecture UM. There are there are a few other examples of immutable architectures UM, and so some are very similar to GET, like blockchain UM, in that you elect a bunch of transactions, you have the hash of the previous block, and you compute it's hash, and now that's the reference to the new one. Right.
The difference is that blockchain requires proof of work in order to make sure that that chain never never forks, whereas GET forks are a feature, not a bug. Yeah, we're calling branches and that's how we do work. But the main thing area is no information is ever destroyed. Right, it's immutable, it's always there, exactly. I mean we've advocated for this and
databases for the longest time. Is these sort of insert only tables journal style tables because we want like a bank, we want a record of every motion of money, every change, even if the sums come later. Right, and more important is just the motion. Yeah, exactly, exactly, Yeah, you need that immutable history. Yeah, except then when you got to do a report. So immutable architecture is one where data is never destroyed, right, right, Not great for reporting, Nope, not great for reporting
at all. Yeah, use something up for that. Yeah, but but yeah. Another another example that that people might already be familiar with is event sourcing. So that is a third immutable architecture. I would say in that list that basically, UM, there has to be some stream that puts those events into a sequence, or at least in a piece wise sequence. So for this particular aggregate, these are the sequence of events that have occurred. And now from that you can compute the current state. Right, And so
a lot of people build applications using using events sourcing UM. In in my book The Art of Immutable Architecture, I introduce a fourth immutable architecture that I call historical modeling that is also suitable for building applications, but has some of the advantages of get UM as compared to things like events sourcing. Okay, so your product Jannaga, did I say it right? Yes? Okay,
perfect? So you said this is sort of it kind of sounds like an actor model pattern for mobile, but not really because an actor model has like these these actors um in memory on a server somewhere that represent a client. Yeah, isn't that right? So this is a little bit different, isn't that? Yeah, it is a bit different. Um. And And another significant difference is that with the actor model UM, the actors have mutable states.
Right, you send a message to an actor, it can load a state, mutated, save it back and tell you what the answer is, right, whereas with an immutable architecture, mutation forbidden, right right, just not not a thing you must love f sharp I actually do. Yeah, I don't. I can't do to program it very much. But you know now that that dot net has records, Yeah, it's like, oh man, I'm all over those records. So so yeah, the the new version of Jenaga that I'm working on right now, Jenaga, that net um is
taking full advantage of those immutable records. Yeah, yeah, yeah, yeah. The wait till wait till you see how the how the code looks. It's amazing that's very cool. Does the enthusiasm for this? I mean, to me is a guy who's usually worked on performance problems. What I like about all these immutable architectures is they perform very well because they avoid contention, which is usually your performance problem. I mean, is that a reason to
do it? Like? Why else would you want immutable architectures? Yeah? Contention, that's um, that's really close to that idea of conflict free right. UM. So so yeah, if you if you have two nodes that that need to kind of battle it out in order to figure out what the current state is, so you've got that Paxos kind of thing happening, then then you're going to waste a bunch of cycles in order to UM to resolve
those those conflicts. Yea, but but yeah, if you UM, if you have a data structure that that proves that you will not have conflicts even if you are on just a mobile phone and you're disconnected from the from the network for you know, any period of time when you finally do reconnect, there will be no conflicts. Then you don't have to waste time resolve in those conflicts. And UM, while you're disconnected, the user is interacting directly
with that device. They're not waiting on any you know, connection to the network. So UM. So yeah, it gives you some some performance benefits UM you know as well as that that scalability. Is this product and open source product? Does it work on all dot net platforms? What's the story there? Yeah, this is this is an open source project. Um UH. It is is currently uh primarily in JavaScript. UM Jenaga dot net is the the newest incantation of it UM but Jaga JS is UM is for for
the client and for the server. So there's uh UM there's a UM you know MPM installed Jenaga and there's a human installed Janaga dash server. UM. So when you when you running on the server, UM that's to be run
as an express uh node application and it gives you some some endpoints. Then that give you access to its um its internal replicator and then you install Jenaga as as a client in your React application or React native and um UH and then that connects to that replicator and UM and genagages on the client can also UM use UM use the web dB or index dB for um UH for the web in order to support progressive web aps, so you can go offline with your PWA. I was, I was very I did some work with the
nextb Uh last year and I was really impressed, you know. But I was using a wrapper for Blazer around it, which turned out to be great, because man, that's scary stuff. If you're going to deal with it in JavaScript, more power to you, my friend. That's yeah, it's so scary code. Yeah, yeah, Well I'm aiming toward that, uh, that place where as a developer you just have to write the specification, yeah, and then let them let the language, let the platform figure out
the h the behavior. So. Um. So when you're doing a lot of disconnect to mobile apps, you're thinking about, oh, I'm in you know, I'm in connected mode. I'm in disconnected mode. I have code that writes to the local database. I have code that talks to the API. You know, I have code that that synchronizes things together. And so you're you're doing a lot of that bookkeeping yourself as a programmer, right.
Um. But but in Janaga, when I'm when I'm going for is a place where you can say, yeah, here's the fact the user just um just did this thing. You know, they entered some stuff into a form impress safe award that fact just just a jobascript object. Yeah. And then um, here's a specification which says, um, you look for facts of this particular shape where these other related facts exist or do not exist. Yeah, so you write this this pretty much this mathematical specification for you know what
it is you're looking for, and then give me a projection. Turn that into a thing that I could just bind into the screen. Yeah, and then let the run time figure out how to save that to local store, how to talk to the server, how to synchronize those those data sets. Awesome, And that's pretty cool. And I'm gonna interrupt for one moment for this very important message, and we're back. It's done at rocks A Richard Campbell. That's Carl Franklin. Hey, hey, hey, talking to our
friend Michael Perry, late of the Tablet show, very late. I think we did the last tablet show in twenty fourteen. Website doesn't even come up anymore. And the Melvin the website has come up. Who knows that maybe we can at the moment, Yeah, turned his statical. It's always archive dot org. Maybe I'll pull it, pull it up that way, and and it's still apparently on on where all the podcasts are. So, yeah, the podcast engines are still got it. Um. But we're talking a
bit about immutable architectures and I sort of get this. Where does CQRS come into play? And I guess I'll define the acronym command query responsibility segregation because now that you know the words, it makes way more sense command query responsibility segregation, I can. I can boil it down and tell me how. And this is purely from memory. Basically, you have one data source for quarrying and another data source for writing. Is that it? That's one way
of implementing it. Yeah, yeah, it's not necessarily that, um okay as um yeah, Oudi Dahan and and Greg Young would would point out not necessarily yeah, sure, but yeah, that's that's one that's general. Just that I learned that when you write to a data a data source that has eventual consists stancy to the one to the second data base or data source that we acquery from. Right, Yeah, that that is the most common way
of doing things, and it makes a lot of sense. Like you were just saying, you wouldn't want to run reports off of an immutable history of records. Um, that's not what that's for um, so use something else for that. And that's perpectly what cr QRS means to me is that, um, you're going to have something that's really good for those those reports. For that read side, that's your projections. Yeah, so run your reads from your projections, um, and then your rights. You're sending those into
some transactional system. And if that transactional system happens to be a directed a cyclograph of them middle records, you're golden. Yeah, I hear you got events sourcing on your events, So I got this to a subliminal events sourcing every other words in chewing events starcing. But I do appreciate the idea of
optimize the ingress path and optimize the outgress path separately. Right right, that there's an ingress path for orders to be entered, and then there is that One of the output paths is fulfillment, but another one it can be is reporting. They don't have to be Why do one thing everything in one place and basically have suboptimal versions of all of it? Right right? Exactly? Yes? Yes, And now imagine that you could just write a specification what
does your reporting database look like? Yeah? And then computer you figure out. Okay, whenever this event happens, go update that table. Right, that's computation, that's machines. Yea, you could solve that. But I mean this is where you get into that sort of relationship mapping thing. It says, this is what the incoming stream looks like. Maybe it's blobs, you know, it doesn't really matter, whatever it comes to, and it
maps it out asynchronously the transaction. It has already been received, but a syncreitly now distribute it to various sources that care for it. Yeah. Yeah, oh and you've got to have a queue in there somewhere, or at least at least one. Yeah, that's okay. Wow, that that is UM. So I want to kind of kind of kind of tie this back to UM what we were just talking about with event sourcing. UM I do I do uh uh I do offer an alternative to event sourcing as a different
immutable architecture that I call historical modeling UM. Whereas event sourcing is this, UM is this at least piece wise uh linear set of of events a historical model UM. They they don't have to be linear, they don't have to have occurred in a in a specific order. Um, it's not tied to the data per se, it's tied to them. Yeah yeah. Let me let me see if I can give a practical example. So, um, so yeah, you you placed an order, say yeah, you know as
a customer. Um, and then what's the next thing that's probably going to happen. Well, the you know, the shipping department is going to pick that up and they're going to create a picklist. But also the accounting department's going to pick that up and they're going to create an invoice. Yep. So the picklist and the invoice are both historical facts. There there happened,
They happened. There's their decisions that somebody made based on that order. So if you model that as a tree, you'll see here's the order at the top, and then the picklist and the invoice are two leaves of that tree, both pointing up to that common route. So it makes a little triangle. Yeah. Yeah, I would argue the picklist is fulfillment. Shipping is another task. Again. You know that you end up with this series of
artifacts related to the order, and they're all done to different people. Sometimes they're sequential. You need to be picked before you can ship and in theory, you shouldn't invoice until you ship. Yeah, but the tree architecture sounds like handles that. However, you want to branch it. Yeah, yeah, exactly. Yeah, so shipment is another historical fact that that points back to the pick list. The shipment doesn't care about the invoice, no,
so it's just pointing up to the pick list. Yeah, there's a there's an accounts receivable, which is actually just a report that you run from invoices. So their accounts receivable itself isn't not a new factor, but the payment is another another element is another fact. Yeah, and that points to the invoice, but the payment doesn't point to the shipment or to the pick list. So you've got this this this tree, this graph that branches m and
now do now do a partial return or a warranty replacement? Like and you can tell the architects in the room because you get all really excited, good white boards drawing for you. Yeah, but you're looking for those dependencies and what they're related to and where we can make them execute independently like this. You're also unique units of work for development too. Yeah. Yeah, this is how it's always that question of how do I get six people to work
on this. It's like, well, because you peel out the one piece, the payment engine, and that goes to one person, maybe two. If you're doing a little pair of programming, you want two sets of eyes on things, and then others are on other pieces. Like you have these, you know, areas of concern that have discrete interfaces on them that allow you to paralyze development, right, exactly. Yeah, And so the same reason that I shipped two copies of Mythical Man month to every manager so they
could read it twice as fast. And I'm going to read Michael's mind here. He's saying what I would do is I would write the engine and then have one guy right the spec for everything, and then the engine does it all right, yes, yes, and that's what we want. Yeah. And the person who writes the engine doesn't even know about your problem, doesn't care, and he's long gone No, he's got a problem factory somewhere. Exactly. Oh, one of my favorite jokes. All right, these are
a whole bunch of insider architect jokes. I'm pretty sure we're making fun of ourselves. I had a problem, so I use Java. Now I have a problem factory. It's an old joke, but a good one, and you have to say it's slower than that because you know Joba. Yeah right, all right, I'm not shouldn't make fun of Jab. Those guys do good work and they're more like us than different. That's true. It's not fair at all, and there no reason to be mean to them. They
have oracle for that. Man. How much time do you spend doing architecture that, Michael, I mean you work for an agile practice group, right, yeah, yeah, I work for Improving and yeah, so we we offer consulting agile training, and so my role at Improving is to help help other improvers grow their careers and also, by the way, bill clients.
So so yeah, I'm um, yeah, I'm often running a team at a client, So in addition to helping to to grow that team, I'm in charge of the architecture for the project as well as often doing you know them you know, technical lead role, right because I mean presenting a directed bicyclic graph to the average developer, they're they're like, where do I log in? Like, it's it's not a product, right, it's a thinking model. And then you get into questions about well, how do I implement
this? Like, is there a library that will drive me towards a Dagum? I don't start people there. Um okay, yeah, so I start people first with analysis. Let's use a director bicyclic graph in order to analyze the problem, and that uncovers all sorts of edge cases, but then also gives you a way to document them. So you say, okay, you
know, like the the the returns that you were just talking about. Yeah, So the breakdown and giggles we just had was actually working through the graph of a retail workflow or an e commerce workflow, right, I mean I've done so many times I don't even laugh about it anymore. Right, this is just like it's the number of times you figured out, are we going to do back ordering? How do we do returns? You know, do
we do unify where you can deliver back to the store? Like yeah, and and just drawing out those diagrams, like I think you forget how weird it is. Yeah, yeah to think about business processes that way. Yeah, And a lot of times people will draw those diagrams as as flu charts or as state transition diagrams or you know, the more modern equivalent to draw those ash as a sequence of events. You know, do some events storming,
right. Um. But the the the diagram that I that I propose is one where you've got an ellipse that represents one historical fact, one decision, right, and then it's got arrows pointing up to the predecessors, those decisions that had to have come before, right. Um. And so now you can walk this tree or this graph really in um, in any order as long as it's from the from the past to the future, from the top down. Um. So you have to follow those arrows backwards, I
like from arrows backwards. But uh, but but yeah you can. You can. You can take any of those paths at any time, and you can describe all sorts of different scenarios with that same graph. So it ends up being a lot cleaner, a lot easier to understand than a flow chart or a or state machine that does the same thing. Yeah, I do appreciate that it's more representative of the problem space ultimately to say, it's sort
of really organizing by artifact, Yeah, exactly. And so then once once I've got people thinking in terms of a director day cyclic graph to analyze the problem. Then we can start talking about how do you implement based on right, And even for that, I don't jump to hey, let's use Janaga Instead, I say, all right, you're used to relational databases. Relational databases have foreign keys. A foreign key is a reference to another record.
So what if every record was an immutable historical fact and those those foreign keys were the coiners to your predecessors. Let's actually build a database like that. I've I've done a number of systems that way, and it's it's really really powerful. What about structures and data like like I'm thinking of lists of objects
of things. If you already use immutable disimmutable architecture where you have records, now you've got duplicate records that you know, no, this is the current one, and these are the historical ones that could get Harry, couldn't it. Oh yeah, that's that's that's a really fun problem. Um. So yeah, there's a pattern that I that I go through in the book called the mutable property pattern. Wait, you just said immutable. You called this
the immutable immutable property. What's he broke his own rules? Yeah, so this is a way all the other farmers on tattooing think of you because yeah, this isn't right, but the um but yeah, the idea is that you were going to simulate mutability using immutable records and um. And so the way that I that I simulate a mutable property is that I've got a historical fact that says the value this property is this value, and the prior value, the one that I just replaced, is that one. So it's the
predecessor. The pointer to the other fact is the previous version of that of that property. Now, what's really cool about this is if you think about this not in terms of a sequence, but in terms of a graph, you can have concurrent changes to a property. You're can have somebody and you can have on their cell phone somebody else on the website, and you both create these facts that point back to the same prior version. Right, and so you've created a tree. You're okay with a tree. Then that two
facts could be pointing back to the same historical facts. Yes, yes, exactly, you are crazy, mister Perry. But but yeah you're used to that as well. In get I'm just curious. No, all right, So this is how strings work, isn't it inherently how strings are immutable objects that when you say, you know, my string variable equals this and then equals this plus that, you're actually creating a new string that from this plus that, and the string that just had this in it is gone. It's
it's marked for death. That's it's unusable memory. Now freed memory. Yeah, so it's well, it's not immediately freed, it will be it is. It is immutable, so you've you've got that part. The thing that strings don't do is keep track of what was the previous string in this variable, right, Yeah, you can't undo a string for example. Yeah, but but string dot undo. Yeah, taking it back to to get It's perfectly fine to have two different commits that point back to the previous commit.
You've just cut a branch. Well, yeah, all perfectly fine until you you try and merge and nobody's fine. Or you try to do a link query to to find some records in the in your record list. Uh huh, yeah, okay, let's let's put a pin in the link query one. Okay, yes, that's really cool. Um, but but merge, I do want to I would do want to talk about that. So in in critt is one of the One of those operations that this data structure needs to perform is a merge operation, but it's not the same as a get
merge. Get is a cr DT. So if you were to if you were to fetch from a remote, now you're performing a merge. You're taking information in that remote and you're merging that information into your own directed a cyclic graph on your repository. Actually performing a get merge creates a new commit, So that is an actual change, that's an update, that's creating a new historical record. And now that you've created that, you can push, which
is a merge in the opposite direction. So so yeah, the thing that we call merge and get, which is so painful, it's actually not a merge. And the thing that we call emerge conflict in get is not a conflict in the term of in the CRDT world, because as a CRDT it
should be conflict free, right right. What's actually happening is the interpretation of what this history means now has has been called into question because you've got concurrent edits, And that's exactly what's happening when you've got these mutable properties that two people change at the same time. Now you're calling into question what does that mean? And the data structure itself, it's not in conflict. It's got
a graph that has two leaves on it. That's perfectly fine. And now your interpretation of it is where you say, oh, was it this phone number or that phone number? Which one is it? And then the way I like to do that is to allow a human, just like can Get, to resolve that conflict, to make the decision which is the correct phone number, and then create a brand new historical fact that points both of them, just like can Get when you do emerge commit it points to both of
its parents. So it was looking at Get for you. The sort of impetus of this pattern that you're describing. I mean, you seem to be referring to Get a lot or was it like, oh, Get does this thing that's in my brain? How fortuitous? Yeah, it was. It was a little bit more of the latter, because I first had this idea of um, of you kind of paying attention to the history rather than the current state around two thousand and one, and I wasn't um yeah, I
wasn't familiar with it. If it was around at that time, Um No, I don't think so. Yeah, but but yeah, then then I kind of started to evolve this and then I saw, oh, there's event sourcing. Oh, that's that's also paying attention to the history and not the current state, but in a different way. Interesting that that feels about. Right, Oh, here's a get Oh that's doing this thing in a much more familiar way, but just for source code, whereas I want to do
this for every vacations in general. Yeah. Oh, that's so a lot of things. It all kind of felt familiar, well all happening at the same time. All right, well that's wow, that's really cool. So I've just one more question before we go. When you go out on a clear night and you look up at the sky, do you see two full moons? Uncle? And this are too? You know it's got a bad
motivator. No, seriously, this is mind blowing stuff. And just to be able to think this way and apply it to common things that you're using everyday life and now could it how could it make things better? Yeah? I love that. Yeah, it's it is. It is amazing when when I'm able to bring a development team along with me and we use this as the way of thinking about a product about the way that we developed the product.
It really comes up with something, you know, much better than we could have done that at it. What's the name of the book again? The book is called The Art of Immutable Architecture Excellent and you can get it wherever fined books are sold. I take it. Yes, you can go to immutable Architecture dot com. That will give you a link directly to it. Do you have an audible version? Um, I do not yet have
an audible version, but yeah, it would be a great idea. Well, don't ask me to read it, because I love all nobody expects all the w T apps. I will read it however. So yeah, this is great stuff. Michael. Thanks, thanks very much for being with us today. Thanks, thanks, thank you. All right, We'll see you
next time on dot net rocks. Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at pwop dot com. Visit our website at dt n et r o c ks dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded in September two thousand and two. And make sure you check out our
sponsors. They keep us in business. Now go write some code. See you next time you got a band,