Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads? Easy? Become a patron for just five dollars
Speaker 1: a month. You get access to a private RSS feed
Speaker 1: where all the shows have no ads. Twenty dollars a month,
Speaker 1: we'll get you that and a special dot net Rocks
Speaker 1: patron mug. Sign up now at Patreon dot dot NetRocks
Speaker 1: dot com. Welcome back to dot net rocks.
Speaker 2: I'm Carl Franklin and Emiratetry Campbell.
Speaker 1: How you doing, buddy, I'm all right, you know.
Speaker 2: It's the weather's been nice. Things are on the swing.
Speaker 2: I got a few more events to do. By the
Speaker 2: time this show comes out, I should be almost on
Speaker 2: the way home from the last of the spring shows. Right, yeah,
Speaker 2: I'm gonna try and spend the summer home.
Speaker 1: Wow.
Speaker 2: Not something I'm good at, as you well know. Yeah,
Speaker 2: that's been the goal.
Speaker 1: Well, if you feel an itch to move to be
Speaker 1: on my side of the country, you always have a
Speaker 1: place to stay.
Speaker 2: Well, I appreciate that. That's very kind of you. Yeah, yeah, yeah,
Speaker 2: you know. As much as I enjoy the travel, I
Speaker 2: do live in a beautiful place, and I in the
Speaker 2: summertime it is especially nice, right, right now. It's a
Speaker 2: spot pronze season, So two o'clocking can pop down to
Speaker 2: the government dock there and pick up a pound of
Speaker 2: spot prons for twenty bucks. That is amazing. I just
Speaker 2: wanted to remind you in case you were thinking of
Speaker 2: traveling to the East Coast, that two thirds of the
Speaker 2: Monday's crew live within fifteen minutes of each other. Yeah.
Speaker 2: It's almost old day times it You guys are all
Speaker 2: close together again. This is how that show got started,
Speaker 2: I know, right, Yeah, I'm kidding.
Speaker 1: Okay, this being episode two thousand and six, we thought
Speaker 1: we'd start with the top ten news items of two
Speaker 1: thousand and six. The Iraq War isn't going well.
Speaker 2: Yeah you never did, yeah.
Speaker 1: Sadam Hussein.
Speaker 2: Winter Olympics. Yeah okay, yeah, Winter Olympics. There was something
Speaker 2: good happening to you that.
Speaker 1: Say, Winter Olympics. Very good. Sadam Hussein bit the dust.
Speaker 2: He had a trial first and they sent him to
Speaker 2: death and then they killed him.
Speaker 1: North Korea conducted its first nuclear test supposedly, but well,
Speaker 1: I'm not sure if it was a fizzle or not.
Speaker 1: There was some funny chemistry there. Yeah, but they've had
Speaker 1: some successful tests since then. We think, so, yeah, Israel
Speaker 1: and Hezbollah warrant in Lebanon which continues to this day,
Speaker 1: and various with various.
Speaker 2: On and off. This is twenty years ago, so yeah.
Speaker 1: The midterm elections shifted control of Congress. Democrats won control
Speaker 1: of both the House and Senate in the November elections,
Speaker 1: seen largely as a public rebuke of the Iraq War
Speaker 1: and the Bush administration.
Speaker 2: Americans don't like wars, oddly.
Speaker 1: Enough, no, no. The Mohammed cartoons controversy worldwide protests and
Speaker 1: violence followed publication of cartoons depicting the prophet Mohammed in
Speaker 1: a Danish newspaper. That was pretty big deal. In the US,
Speaker 1: there was protests over immigration reforms and border enforcement legislation.
Speaker 1: The Iran nuclear crisis intensifies. Boy, this sounds like this year,
Speaker 1: doesn't it.
Speaker 2: It's kind of creepy. Yeah, yeah, it's a weird. Twenty
Speaker 2: years on.
Speaker 1: Fidel Castro temporarily gave up power.
Speaker 2: Well he's not doing that anymore.
Speaker 1: Raoul in charge, and global attention on climate change was
Speaker 1: the mainstream political issue worldwide. You're driven in part by
Speaker 1: Al Gore's documentary and Inconvenient Truth, which was really good
Speaker 1: and a little scary.
Speaker 2: Yeah, had a lot of bad news to share, and
Speaker 2: you know, some of which it's it's tough to do
Speaker 2: the praditions he was doing, so they didn't quite panel
Speaker 2: the way he was talking about. Certainly we're seeing the
Speaker 2: consquatches of that.
Speaker 1: Well, before we get to Tech in Space with Richard,
Speaker 1: let me just run down the top ten movies grossing
Speaker 1: movies of two thousand and six. Number ten Feet, That
Speaker 1: was fun, Number ons Penguins, number nine, Superman Returns number eight,
Speaker 1: Mission Impossible three, number seven X Men. The Last Stand?
Speaker 1: Was it really the last stand?
Speaker 3: No?
Speaker 2: They kept we kept coming around again, I know, yeah, cars,
Speaker 2: Oh yeah, that was good.
Speaker 1: Maid Night at the Museum Rob Williams, which was kind
Speaker 1: of weird, but kids loved it. Casino Royale number three,
Speaker 1: Ice Age, the Melkdown number two, the Da Vinci Code,
Speaker 1: Oh twice as much money. It made twice as much
Speaker 1: as Happy Feet, and number one, Pirates of the Caribbean,
Speaker 1: dead Man's Chest about one billion dollars. Quite a franchise,
Speaker 1: whereas Da Vinci Code was seven to sixty million.
Speaker 2: All right, how about that crazy?
Speaker 1: All right? Tech in Space in two thousand and six,
Speaker 1: laying on me.
Speaker 2: Do you know how you still can't carry a bottle
Speaker 2: of water on an airplane? Yeah, that comes from two
Speaker 2: thousand and six. Oh yeah, that's the intelligence forces figured
Speaker 2: out that there was a plan to use soda bottles
Speaker 2: to carry liquid explosives onto airplanes, and they have banned
Speaker 2: liquids ever since. That's when that started. But let's get
Speaker 2: to the space stuff.
Speaker 1: Unless you want to buy them. Once you're through the gate,
Speaker 1: then they're okay for some reason.
Speaker 2: Oh yeah, once you've gone through, once you've gone through
Speaker 2: security here.
Speaker 1: Yeah, all right.
Speaker 2: On the space side, January is a crazy month because
Speaker 2: this is when star Dust the mission we've mentioned a
Speaker 2: couple of times, because they did a bunch of different things,
Speaker 2: collecting particles of interstellar space and also partiles from comets.
Speaker 2: So it had been launched in nineteen ninety nine. He
Speaker 2: did a fly by the asteroid and Frank in two
Speaker 2: thousand and two, then flew through the plume of Wild
Speaker 2: to the comet in two thousand and four. In two
Speaker 2: thousand and six, its sample return mission was dropped by
Speaker 2: on the Earth with those different particles, including the comet
Speaker 2: materials from Wild two that showed both water and glycine
Speaker 2: the proto amino acids for creating life. That wasn't actually
Speaker 2: the end of the Stardus mission. From there, they reper
Speaker 2: pristed to go off and intercept Temple One, which we
Speaker 2: talked about in a previous show, where deep impact had
Speaker 2: blown a hole in that comet. It wasn't able to
Speaker 2: heat images because there was too much debris started as
Speaker 2: was able to intercept it and get those pictures. Yeah.
Speaker 2: Also in January, the New Horizons launched. That was the
Speaker 2: high speed mission to Pluto. High speed being a relative concept,
Speaker 2: of course. It was launched on an Atlas five at
Speaker 2: maximum power. Was the first time we've ever put a
Speaker 2: satellite directly on a escape velocity of the Solar System.
Speaker 2: Every other spacecraft needed to do additional burns or gravity
Speaker 2: assists flybys New Horizons. We kept it light enough that
Speaker 2: it could just drive it straight from Pluto, although it'll
Speaker 2: still take years. In March, the Cassini mission is underway,
Speaker 2: and this is when they first get an image. They've
Speaker 2: been taking images of Encettalists and Settlists. Was thought to
Speaker 2: just be an icy rock that was highly reflective, and
Speaker 2: in late two thousand and five and two thousand and
Speaker 2: sixty get the images of the geyser plumes, and I
Speaker 2: remember that that arguably become so important they redirect much
Speaker 2: of the Cassini mission to gather more data around that,
Speaker 2: and really and settlists will change the way we think
Speaker 2: about where life can exist in a Solar system, because
Speaker 2: here's this little icy rock orbiting a gas giant. It
Speaker 2: shouldn't make any sense, and yet it's clearly has a
Speaker 2: liquid water ocean under its aol, which Cassini will help prove.
Speaker 2: Also in March, the Mars recon enters the orbit around
Speaker 2: March and is still operational today. In April e says,
Speaker 2: Venus Express mission gets into orbit around Venus to do
Speaker 2: some mapping there as well. In July we get the
Speaker 2: returned the second return to flight after the Columbia disaster
Speaker 2: on Discovery, where they take supplies and crew to the ISS.
Speaker 2: In September, Atlantis will be the first mission to do
Speaker 2: assemblies onto the ISS since two thousand and two, and
Speaker 2: also December Discovery will do the same. August is also
Speaker 2: when the International Astronomical Union defines the planet and demotes
Speaker 2: Pluto to be a dwarf planet. Went to the consternation
Speaker 2: of many and still a debate going on today. Also
Speaker 2: in two thousand and six, a small startup company called
Speaker 2: SpaceX does their first flight of the Falcon one from
Speaker 2: Amelek Island in the Quandulin Atoll. This was paid for
Speaker 2: largely by the Department of Defense under their prob Prompt
Speaker 2: Global Strike initiative, and it's supposed to fly in two
Speaker 2: thousand and five, but it got bumped out. It does
Speaker 2: not go well. It has a primary engine failure after
Speaker 2: thirty three seconds of flight and falls into the Coral Atoll.
Speaker 2: The twenty kilogram satellite lands on a storage shed near
Speaker 2: the site. Turns out it was a break in a
Speaker 2: fuel line and it was not a misinstallation. The rocket
Speaker 2: had been waiting long enough that saltwater corrosion had damaged
Speaker 2: the pipe.
Speaker 1: I think SpaceX is a study in how to learn
Speaker 1: from failure.
Speaker 2: And they did a pretty good job. And they'll fail
Speaker 2: a few more times too. That being said, in this
Speaker 2: same year, SpaceX has awarded a four hundred million dollar
Speaker 2: contract to develop crew and cargo resupply for the ISS.
Speaker 2: There was considered a long shot, but that was the
Speaker 2: funding that started Faulcon nine. Over on the computing side,
Speaker 2: two thousand and six is when Jack Dorrisy launches Twitter.
Speaker 2: Oh yeah, and Google, now a public company buys YouTube
Speaker 2: for one point six billion dollars. They'll probably make I'll
Speaker 2: just fine on that for sure. Amazon launches their Amazon
Speaker 2: Web Services with both EACY two and S three, beginning
Speaker 2: a revival of the term the cloud.
Speaker 1: Yeah, that's right.
Speaker 2: There's a reunion between McCarthy and Minski for the fiftieth
Speaker 2: anniversary of the original AI project from nineteen fifty six.
Speaker 2: Juliana Sans launches wiki leaks that went well.
Speaker 1: Yeah.
Speaker 2: Also in January, John Resik pushes out the first open
Speaker 2: source version of jQuery. Right and when she'll become very
Speaker 2: important in the Microsoft world, probably the first open source
Speaker 2: product that Microsoft ever ships in the box, so to speak,
Speaker 2: in the box twenty ten a few years away. In March,
Speaker 2: the first of the mixed conferences mix O six, where
Speaker 2: they announce I E seven.
Speaker 1: I remember it fondly from what I remember of it, yeah.
Speaker 2: Which should have been six years. And in May they
Speaker 2: also well and back in March, I announced Coplex. In May,
Speaker 2: Coplex goes live as Microsoft's source control or open source environment.
Speaker 2: Although it's not the way we think of open source. Then, Yeah,
Speaker 2: they're building the code internally and publishing it on coplex
Speaker 2: people to downwold, play with and provide feedback, right, and
Speaker 2: they're doing a rapid series of feedback sequences there.
Speaker 1: It wasn't really like what gid hub would turn out
Speaker 1: to be.
Speaker 2: No, you can't contribute code to this at this point
Speaker 2: in the cycle. And in the fall Windows Vista and
Speaker 2: a byproduct of Windows Vista dot Net three, the version
Speaker 2: of dot net that wasn't really a version of dot
Speaker 2: net more catching all the fallout of Vista. So it's
Speaker 2: still actually dot Net two, but it adds WCFWPF workflow
Speaker 2: and card space.
Speaker 1: Yeah. Three letter acronyms.
Speaker 2: Yeah, because they all had cool code names. Go from
Speaker 2: Avalon and Indigo to Windows Communication Foundation Presentation. Fortunate, But
Speaker 2: in that earlier announcement it mixed. They talked about w
Speaker 2: p F E as it was a Windows Presentation Foundation everwhere.
Speaker 2: And by December they will ship the first community technology
Speaker 2: preview via Coplex that they would eventually call silver Light
Speaker 2: V one with no dotinant in it whatsoever.
Speaker 1: In my heart right, okay, yeah, is feeling it part
Speaker 1: with his finger. I remember Rory Blake, what did he
Speaker 1: say about silver Light one point zero? It's basically an
Speaker 1: animated gift downloader with an API or something.
Speaker 2: Yeah, more or less, because it was they're really building
Speaker 2: it for Netflix. It was going to be part of
Speaker 2: the media playing system, and it was all JavaScript driven
Speaker 2: at that point. The net part will come later. Those
Speaker 2: are early days. Also launch in two thousand and six
Speaker 2: the Zoom Zoom, Yeah, the zoon. This is when a
Speaker 2: project called Monad gets renamed as PowerShell oh yeah, yeah wow.
Speaker 1: And two thousand six also the Striking a Lot of Memories.
Speaker 2: Oh yeah. Two thousand and six is also the year
Speaker 2: that Bill Gates steps down as chief architect and Ray
Speaker 2: Aussie takes over. And last, certainly not least, the first
Speaker 2: episode of handsel minutes mm hmmm, Ye, our friends got
Speaker 2: Handsoman decides he too needs to make a podcast, but
Speaker 2: maybe not as long as what we were doing. Yeah,
Speaker 2: and so he called it Handso minutes.
Speaker 1: Right after we started, we were a tech ed and
Speaker 1: he was buzzing around on a segue and he would
Speaker 1: come I'm doing an interview. I'm interviewing somebody, and he'd
Speaker 1: come in and stick his head in and go podcasting
Speaker 1: sucks and drive off. And it turns out, you know,
Speaker 1: after talking to him, after he'd calmed down a little bit,
Speaker 1: he didn't really mean podcasting sucks. He met podcasts sucks.
Speaker 1: There you go. Other than what we were doing, the
Speaker 1: podcasts out there that were sort of the you know,
Speaker 1: the start of podcasting as we knew it. We're just
Speaker 1: kind of chatty and you know, not a lot of substance.
Speaker 1: So I think he did confirm it that's really what
Speaker 1: he meant, because he went on to do handsome on it, yeah,
Speaker 1: which didn't suck.
Speaker 2: It does not song still doesn't soun No, that's what
Speaker 2: I got, all right, Yeah, okay with that, let's roll
Speaker 2: the music for better no framework awesome? Alright, man, what
Speaker 2: do you got?
Speaker 1: So like most times when i'm you know, grasping for
Speaker 1: straws at the last minute, I went out and looked
Speaker 1: for trending repose and this one just struck me as
Speaker 1: kind of funny. It's called closed xml. Oh. Closed xml
Speaker 1: is a dot net library for reading, manipulating, and writing
Speaker 1: Excel two thousand and seven plus files, which are xl
Speaker 1: s x Right.
Speaker 2: In two thousand and seven is when Microsoft switched over
Speaker 2: to an XML file format for Excel and everything else
Speaker 2: xl SM.
Speaker 1: Also it aims to provide an intuitive and use a
Speaker 1: friendly interface to dealing with the underlying open XML APIH
Speaker 1: And that's where I thought it was funny because it's
Speaker 1: using open XML. But they call it closed XML.
Speaker 2: Troublemaker.
Speaker 1: So it's still in early days. But you know, if
Speaker 1: that's the kind of thing that you want to go
Speaker 1: check out, go check it out.
Speaker 2: To be able to directly read and write to an
Speaker 2: Excel spreadsheet, I can think of some trouble I'd get
Speaker 2: into with that. I remember calling calm objects to Excel
Speaker 2: on a server to stuff stuff and do an Excel spreadsheet.
Speaker 2: This would be a better way.
Speaker 1: You think that's crazy, try using a calm object to
Speaker 1: manipulate Skype remember that?
Speaker 2: No, thanks, We used to do that. We used to Yeah,
Speaker 2: we learned, we learned to stop.
Speaker 1: Anyway, that's what I got today. Who's talking to Richard.
Speaker 2: Grab the comment off a show two thousand because I
Speaker 2: thought it'd be fun to grab a couple of those.
Speaker 2: And here's a comment from his mail says, congrats boys,
Speaker 2: I became a listener back in two thousand and eight. Well,
Speaker 2: searching for share points content. Yeah, sorry, sorry, you're sorry
Speaker 2: about that. Throw all those lives ups and downs, and
Speaker 2: even stepping away from the industry, I always find myself
Speaker 2: coming back for the comfort and sense of sanity. All right,
Speaker 2: I think your crazy matches are crazy. Here is no
Speaker 2: because I'm the sanity's always questionable. But he says, it
Speaker 2: always felt like catching up with friends. Well that's good,
Speaker 2: that's nice, thanks man, appreciate it. And so copy of
Speaker 2: music Coby is on its way to you. And if
Speaker 2: you'd like a copy of music Cobe, I write a
Speaker 2: comment on the website at dot netroocks dot com or
Speaker 2: on the facebooks. We publish every show there and if
Speaker 2: you comment there and I read it on the show,
Speaker 2: we'll send you copy of music O.
Speaker 1: By all right, And that brings us to our guest today.
Speaker 1: Ingebrigston is a Norwegian event sorcerer, software developer, architect and
Speaker 1: his day to day job is working as a technical
Speaker 1: advisor at Nova Net. He's the creator of Kratis. Did
Speaker 1: I say that right?
Speaker 3: Yeah?
Speaker 1: Cretis cr tis. I got that last summer when I
Speaker 1: was in a pool and nice for.
Speaker 2: Anyway, Yeah.
Speaker 1: Cratus and open source event sourcing q CQRS and productivity
Speaker 1: platform for dot net. His passion lies in building quality
Speaker 1: software that improves the lives of end users, and his
Speaker 1: focus has been on event sourcing an event driven architecture
Speaker 1: since twenty ten. I'll let you read the rest of
Speaker 1: his amazing bio on the website dot rocks dot com.
Speaker 3: Welcome miner, Oh, thank you, thanks for having me and
Speaker 3: the congrats on your two thousand kind of show milestone.
Speaker 3: It's quite amazing. I've been following you guys since I
Speaker 3: guess mid two thousands, and you saved many a commute
Speaker 3: for me.
Speaker 2: Appreciate it.
Speaker 1: I guess that's true. Part of the part of the
Speaker 1: allure of dot net rocks is just to hear people
Speaker 1: talking about stuff that you're doing right and using the
Speaker 1: same vocabulary.
Speaker 3: Yeah, yeah, absolutely, it's I mean, the service you're doing
Speaker 3: is with kind of bunk. I've thought I kind of
Speaker 3: learned a lot from you guys, right, so I think
Speaker 3: a lot of people do right.
Speaker 1: So events sourcing very very cool stuff in cqrs as well.
Speaker 1: You gave us some show notes and talking points, and
Speaker 1: you your starting story, your origin story in computers is
Speaker 1: really kind of fun. So yeah, talk about that maybe
Speaker 1: a little a.
Speaker 3: Sure, So I guess is this is early eighties, as
Speaker 3: kind of any kid of the eighties, well who we're
Speaker 3: curious about technology got a computer, and more often than not,
Speaker 3: it was probably a commod Our computer. Right, So I
Speaker 3: started off with a I got for Christmas, like a
Speaker 3: Commodore Week twenty kind of thing and nice. The fun
Speaker 3: part is that I was living in a on the
Speaker 3: the countryside basically, so there weren't many people around, so you, well,
Speaker 3: you didn't have a lot of friends and all that.
Speaker 3: So my best friend was actually my uncle, and he's
Speaker 3: six years older than me, so it wasn't too bad.
Speaker 3: And he had a Commodore sixty four and my dad
Speaker 3: hasn't had a Commodore sixty four. So at one point
Speaker 3: in time I just basically had a hostile takeover over
Speaker 3: my dad's Commodore sixty four because I wanted to do
Speaker 3: what my uncle was doing. Well, it was basically programming,
Speaker 3: and that got me into like, okay, so basic at first,
Speaker 3: but pretty early actually doing like assembly language on the
Speaker 3: Commodore sixty four.
Speaker 1: Wow.
Speaker 2: Cool cool sixty five? Oh too, baby?
Speaker 3: Yeah?
Speaker 1: Yeah, which did you find first, Microsoft programming or sequel?
Speaker 3: I Well, so if you look at my history. So
Speaker 3: in professionally you mean yeah, yeah, yeah, So professionally I
Speaker 3: started actually doing games development in ninety four, and at
Speaker 3: that time I started actually doing my role was basically
Speaker 3: doing two D and three D engine type of things
Speaker 3: on different platforms like first dos Amostos games and then
Speaker 3: later PlayStation and also some Super Nintendo and much later
Speaker 3: also Xbox. Right, so we were very early on doing
Speaker 3: so for the Microsoft part, so Amastos is one thing,
Speaker 3: but there weren't any particular frameworks or anything like that.
Speaker 3: But we were early adopters of the first Direct x one,
Speaker 3: so before Windows ninety five came out, we actually started
Speaker 3: in ninety four starting working on it. We had the
Speaker 3: company that I worked for how to deal with Acclaim
Speaker 3: software at that point, and we were doing Dragonheart, the
Speaker 3: kind of the movie game version rate, and there was
Speaker 3: a deal between Microsoft and a Claim at that point,
Speaker 3: and we got early acts us two Direct X one.
Speaker 2: So cool.
Speaker 3: That's my first introduction to really kind of Microsoft, if
Speaker 3: you will, right, but then C plus plus of course at.
Speaker 2: That time, learning the early version of DirectX that's a
Speaker 2: cruel way to start, my goodness. They were still trying
Speaker 2: to figure out what they were trying to do there,
Speaker 2: not bit blitting anymore.
Speaker 1: Yeah, exactly, C plus plus I imagine.
Speaker 3: Yeah, yeah, yeah definitely. And you were talking about like
Speaker 3: calm objects. That was kind of my introduction to calm objects, right,
Speaker 3: because direct x was so calm right.
Speaker 2: Yeah, well it was bigger and heavier. It wasn't meant
Speaker 2: for gaming, that's for sure. Yeah, Microsoft trying to find
Speaker 2: a way to make because we were still kicking into
Speaker 2: Dosmo to play games right then, right, because Windows was
Speaker 2: just too sluggish for that sort of thing. There was
Speaker 2: no way, just not the way you're right to the screen.
Speaker 1: So when I remember the engineers that I worked with
Speaker 1: that were doing Colm told me at the time was that,
Speaker 1: you know, calm, once you have an object loaded and
Speaker 1: in memory, it's really fast, you know, but it's that
Speaker 1: whole discovery and loading thing that that is slow. I remember.
Speaker 1: I think it was Garysnewsky who said, you know, Calm
Speaker 1: is this beautiful, you know, evocation system surrounded by a
Speaker 1: bunch of baroque bullshit.
Speaker 2: He wasn't wrong, you had to interact with everything, but
Speaker 2: you know, yeah, sort of the reality.
Speaker 3: But if you look at it, like the original idea
Speaker 3: was still very sound, because that's what we're trying to
Speaker 3: aim for today as well with like reworte procedure goals.
Speaker 3: But in a Yeah, so with service discovery and all that,
Speaker 3: that was actually with a query interface and whatnot sitting there.
Speaker 2: Yeah, we still have to keep resolving that problem every solfet.
Speaker 2: How do I discover services? How do I understand how
Speaker 2: to communicate with them? Then how do I communicate?
Speaker 3: Yeah?
Speaker 1: So what got you into events sourcing? An event modeling
Speaker 1: and all that.
Speaker 3: Yeah, So if you look at my background from gaming,
Speaker 3: what we were doing in the nine we were already
Speaker 3: at that point doing sort of event based systems. We
Speaker 3: were doing message based, right, so we were passing messages
Speaker 3: along and everything was really decoupled, like actor models stuff. Yeah,
Speaker 3: and we had like crude actor models and stuff like that.
Speaker 3: It was like sophisticated stuff that we have today. But
Speaker 3: I was kind of I grew up in that. And
Speaker 3: at one point we actually we moved city, so my
Speaker 3: wife and me we moved city, and then the place
Speaker 3: we moved there weren't that many gaming companies, so I
Speaker 3: basically had to cut my hair I don't have much
Speaker 3: of that and get a real job. And at that point,
Speaker 3: so real job, meaning we'll get into database programming or
Speaker 3: as minor business type of things. And I've always had
Speaker 3: this inkling because I never got to be friends with
Speaker 3: Sequel in a way. Right there was something I felt
Speaker 3: was missing or something that was wrong, and we were
Speaker 3: trying to solve things with the wrong technology right in
Speaker 3: a way, because that particular domain that I was working
Speaker 3: on was also it was in healthcare and we were
Speaker 3: doing like shift management software, so audit trails were a
Speaker 3: thing that was very very important to actually have for everything.
Speaker 3: So and then a fore later years later, actually leaving
Speaker 3: that job, I started doing e commerce. And at that
Speaker 3: place that I started, everything was message oriented in a way,
Speaker 3: so I got introduced into like okay so MSMQ and
Speaker 3: all these kind of things, and I was like, oh, okay,
Speaker 3: this is interesting. And this is right around the time
Speaker 3: when people are now talking about like domainder of the sign.
Speaker 3: We have Eric Evans mentioning domain events, we have Market
Speaker 3: Powler doing the write up on domain events. We have
Speaker 3: the CCRAS thing happening at the same time. It's like
Speaker 3: it's like a perfect storm almost architecturally that's going on,
Speaker 3: and I get really interested into it and we started
Speaker 3: exploring with what could this mean? Like many at that time,
Speaker 3: this is kind of late two thousands in I guess
Speaker 3: in twenty ten we actually make the decision to start
Speaker 3: rewriting the e commerce that I was on to start
Speaker 3: using event sourcing. And my background is, like I said,
Speaker 3: in the gaming industry, I was doing like engine work.
Speaker 3: I was building the three D and two D engines,
Speaker 3: and I love building actually developer tools for developers. So
Speaker 3: my natural role was kind of, Okay, let's build something
Speaker 3: that makes the other developers productive in this new way
Speaker 3: of thinking. This is the event sourcing thing, and that's
Speaker 3: kind of where the snowball started. It's like it's been
Speaker 3: that journey ever since trying to figure out this thing
Speaker 3: because there aren't any like out of the box like
Speaker 3: Microsoft new project the event sourcing things, So it's been
Speaker 3: evolving ever since.
Speaker 1: Right, it's really a technique, not a product, Isn't it
Speaker 1: event sort of thing?
Speaker 3: Definitely is it's But when you start diving into it,
Speaker 3: it's like, Okay, it's definitely a technique, and it's a
Speaker 3: mindset in a way, starting to think about state changes
Speaker 3: rather than your kind of current state. It's more like
Speaker 3: how do we got there? How did we get there?
Speaker 3: But when you start diving into it, there there are
Speaker 3: certainly problems that could benefit from a product that actually
Speaker 3: or a framework up would solve it once for like
Speaker 3: sure compliance and all these things, data integrity, all these
Speaker 3: small little bits and cases.
Speaker 1: Right, So at the application level, at the application level,
Speaker 1: you just do an update, but under the hood, it's
Speaker 1: really writing a new record and dealing with all of
Speaker 1: that stuff in a query the same way.
Speaker 3: Yeah, yeah, definitely.
Speaker 1: So is that kind of what your product is centered around?
Speaker 3: Oh yeah, yeah, absolutely. So if you look at Creators,
Speaker 3: it's a full open source solution. There's kind of different
Speaker 3: products within it. Right, so you have the thing that's
Speaker 3: centered around event sourcing purely is called Chronicle, and it's
Speaker 3: a sort of a database solution. Although the storage engine
Speaker 3: is not something we own. We don't really care about
Speaker 3: the storage engines, so we're very agnostic and right now
Speaker 3: we support like Mongo and pascrus ms SQL and seql
Speaker 3: light as the underlying storage engines. Right. So on top
Speaker 3: of that, we've built a reusable server component basically that
Speaker 3: deals with all the heavy kind of hardlifting. Heavy lifting,
Speaker 3: I mean, for what we think is important problems to
Speaker 3: solve within event.
Speaker 2: So what does that look like? What are my tricky
Speaker 2: problems here?
Speaker 3: Well, if you start with well simple things like projecting,
Speaker 3: because one of the things you need to think about
Speaker 3: is like, okay, we're appending events as they go, right,
Speaker 3: So every time there is a significant domain well change
Speaker 3: i would say yet state change in your system, you
Speaker 3: would be appending that event. But for some scenarios, it
Speaker 3: doesn't make sense to go and actually replay those events
Speaker 3: just to display a list, right of something like a
Speaker 3: master detailed type of scenario where you want to display
Speaker 3: a list of things that you've recorded, like employees or
Speaker 3: something like that. So what you want to do is
Speaker 3: like materialize that, and that's what we do. We've got
Speaker 3: something basically projections. It's part of kind of event sourcing,
Speaker 3: and what you do is react to the events that
Speaker 3: occur and write the current state. And what we've done,
Speaker 3: for instance, is instead of having to imperatively go and
Speaker 3: write that code that does that, because that can be
Speaker 3: very complex when you start having complex models, what we've
Speaker 3: done is create a projection engine that basically can let
Speaker 3: you do relationships like you have a parent child relationships.
Speaker 3: You can join things and from all these different events
Speaker 3: and ordering doesn't really matter. It will just figure it
Speaker 3: out and do the right thing.
Speaker 2: It'll just populate what it gets.
Speaker 3: Yeah, basically, So that's one thing that we're kind of
Speaker 3: very proud of solving because what we're trying to do
Speaker 3: is democratize the events sourcing. We're not trying to actually
Speaker 3: build something that is for the event sourcing geeks, although
Speaker 3: we want to maintain a good relationship with those as well,
Speaker 3: so people that know event sourcing they also should feel
Speaker 3: well right at home. But what we want to do
Speaker 3: is basically, well, make event sourcing easy for everyone. So
Speaker 3: that means we need to make something that feels a
Speaker 3: little bit similar to what they're used to. So if
Speaker 3: you're in a dot netspace, if you're used to like
Speaker 3: NTO the framework, how can you produce events but easily
Speaker 3: project So what we got is, for instance, like attributes
Speaker 3: that you can put on like what we call a
Speaker 3: read model, the thing that we actually materialize. You have
Speaker 3: attributes that feels a little bit similar to antiy framework. Right,
Speaker 3: just to saying from that event and all of a
Speaker 3: sudden you've lowered the threshold for starting right and the entry
Speaker 3: barrier basically for getting started.
Speaker 2: This sounds very brown field friendly. That I could take
Speaker 2: an existing application is start putting event streams into it
Speaker 2: and surface it in a form that you're already familiar
Speaker 2: with from regular database retrieval.
Speaker 3: Yeah. Yeah, so it's kind of similar with when you
Speaker 3: talk about like brownfield. Again, there's also the need for
Speaker 3: actually integrating with the brown Field systems because brownd fast
Speaker 3: systems and producing events. So one of the data that
Speaker 3: we also have built into it is a changed data
Speaker 3: capture language. So what you can actually go and do
Speaker 3: is it's basically the reverse of a projection. So how
Speaker 3: can we go and define state changes happening in a
Speaker 3: database or an API, and when list in this field
Speaker 3: changes together, that makes that event. Right, So we also
Speaker 3: got that covered right, so that because that's super important,
Speaker 3: most products out there or projects out there aren't greenfield,
Speaker 3: so you need to kind of think of that as well.
Speaker 3: How do you sure how do you get people to
Speaker 3: start using it in a brown field scenario?
Speaker 2: Well, yeah, and it strikes me that you're going down
Speaker 2: the wrong path with your existing application trying to stuff
Speaker 2: data into databases and so forth, and realize actually, you
Speaker 2: know this is probably an event sourcing pattern solution, but
Speaker 2: I don't want to start over.
Speaker 1: Yeah, But also when you're doing that brown field thing,
Speaker 1: you really kind of have to commit because on one
Speaker 1: day you've got regular tables and rows and records and stuff,
Speaker 1: and on the next day, what you have an entirely
Speaker 1: different set of tables that you now have to rely on.
Speaker 1: So you have to switch. Like it's It's not a
Speaker 1: piecemeal thing, isn't.
Speaker 3: No, absolutely not. So what you tend to do with
Speaker 3: like when you have a brownfield, what you can do
Speaker 3: is like produce the initial event. So let's say you
Speaker 3: have you want to transfer something over and you started
Speaker 3: like rewriting stuff and starting to produce events, but you
Speaker 3: want that initial load. You can create these events that
Speaker 3: represents that initial load that will be okay, this is
Speaker 3: important event almost right, So you're importing the data that's
Speaker 3: already there as an event. Because one of the things
Speaker 3: that you you don't have to but I would strongly
Speaker 3: recommend thinking about it is the replayability of these things,
Speaker 3: because that's one of the biggest traits I would say
Speaker 3: with event sourcing is the ability to actually replay at
Speaker 3: any point in time. You can from a deburging perspective
Speaker 3: or developer, and you can actually replay from a point
Speaker 3: in time to a point in time and see what happens. Right,
Speaker 3: So it's that power that you're looking for. It's the
Speaker 3: and that gives you a lot of power.
Speaker 1: So not for the developer that replay has to be fast,
Speaker 1: doesn't it. I mean that's been early event sourcing. You
Speaker 1: know you'd have to sit and wait for all those
Speaker 1: things to be calculated. How do you deal with that exactly?
Speaker 3: Yeah, that's actually a good question because it's one of
Speaker 3: the things that we also see as important to solve,
Speaker 3: right if you want people to adopt us. So what
Speaker 3: we built into the thing is as a replay mechanism
Speaker 3: that will actually pull it will do it in bulks,
Speaker 3: so any things into the memory and do things in bulk,
Speaker 3: and do it fast, right, so you can replay pretty fast.
Speaker 3: And what we're also looking at like optimization because we
Speaker 3: have since we have that projection engine that we think
Speaker 3: will cover probably ninety plus percent of the use cases,
Speaker 3: we can do that manner so that means we don't
Speaker 3: have to call your code. That means we can do
Speaker 3: everything in the server. So doing a replay is basically
Speaker 3: in that server and are the entire architecture. Our server
Speaker 3: is built on top of Microsoft or Leans, so we
Speaker 3: can actually scale that out. Okay, so we can do that,
Speaker 3: and we.
Speaker 1: There's your actor actor model coming back to exactly.
Speaker 3: So finally back to where I was like thirty years ago.
Speaker 3: So what that gives us is the since we do
Speaker 3: a replay per petition, and petition for us is more
Speaker 3: like think of it as the primary key, right, So
Speaker 3: if you have things that are related to one employee
Speaker 3: that will typically have a unique key in the system,
Speaker 3: that's the event sorce ide and that's the primary key
Speaker 3: that we will use for replay. So we will then
Speaker 3: replay every one of these keys individually and in parallel
Speaker 3: and just let or Leans scale it basically.
Speaker 2: Good.
Speaker 1: This seems like a good time to take a break,
Speaker 1: so we'll be right back after these very important messages.
Speaker 1: Don't go away, and we're back. It's not in at Rocks.
Speaker 1: I'm Carl Franklin. That's Richard Campbell, hey, and we're talking
Speaker 1: to Einar Inga Brigson's about his creatus and specifically we're
Speaker 1: talking about Chronicle, right, because as you said, there's several
Speaker 1: parts to create us. So we're talking about the events sourcing.
Speaker 3: Yeah, so you could kind of circle back to the
Speaker 3: other things if we get time. But I think the
Speaker 3: if you look at what we're doing with, you asked
Speaker 3: the question of what are the problem or the hard
Speaker 3: tough problems for solving? Right, So I mentioned a couple
Speaker 3: of hours like projection, replay and all these kind of things,
Speaker 3: But one more specific thing is something like compliance. If
Speaker 3: you look at compliance and PII, right, being European GDPR
Speaker 3: and all that, there are certain rules for how you
Speaker 3: actually manage data. So one of the things that is tough,
Speaker 3: well disregard event sourcing is tough actually in regular applications
Speaker 3: as well, how do you deal with PII. So what
Speaker 3: we've landed on is like, so if you looked at
Speaker 3: the GDPR rules, there's this concept of pseudomization, like you
Speaker 3: had to go in and represent Well, you can either
Speaker 3: like put data in a different data store and have
Speaker 3: like a pointer to it and that's your I don't know,
Speaker 3: your token that represents the other thing or what we've
Speaker 3: decided to do is actually encrypted and we want to
Speaker 3: encrypt it not as a there's one key for the
Speaker 3: entire thing, but there's a one key per subject. So
Speaker 3: if you're dealing with the events that's related to like
Speaker 3: a person, that's back to the primary key that was talking. Again,
Speaker 3: the event source ID would be the default for that,
Speaker 3: but you can also specify a subject ID if you
Speaker 3: want to, and we then general a key per that subject.
Speaker 3: That means when our user comes and say, hey, I
Speaker 3: want to be forgotten, which is one of the GITA
Speaker 3: TDPR things that you have to actually implement, we can
Speaker 3: go and then just throw away that encryption, right, that's
Speaker 3: the crypto shredding. Yeah, but not lose the history. So
Speaker 3: we will still have the history, but we would will
Speaker 3: not be able to see the properties on the event. Well,
Speaker 3: we will see what happened, right.
Speaker 1: That's very smart. It's kind of a shortcut if you
Speaker 1: will sort of macros into specific things.
Speaker 3: So those things are kind of hard to solve in
Speaker 3: a consistent way. And when we're thinking about these things,
Speaker 3: we're thinking holistically. So how do we You shouldn't as
Speaker 3: a developer need to think about these things. We should
Speaker 3: just depend an event. And what we do is we
Speaker 3: have this attribute called PII, So you can add that
Speaker 3: attribute to a specific property. You go and added to
Speaker 3: what we call a concept that the main concept, which
Speaker 3: is basically a value type, so a record that represents
Speaker 3: that value, and once you add the PII onto it,
Speaker 3: we will encrypt that automatically for that subject. And the
Speaker 3: beauty about it is that if you use that same
Speaker 3: property or that type on a read model, we will
Speaker 3: decrypt that automatically for you. So for you as a developer,
Speaker 3: this is completely well, you don't have to think about
Speaker 3: it as just yeah, transparent for you. Right. So it's
Speaker 3: those kinds of things, and that's where we're playing a
Speaker 3: little bit into that arc side of things because we
Speaker 3: need that to fit together as a kind of holistic
Speaker 3: model with an application model that supports it as well.
Speaker 3: Because Chronicle has one purpose and that solve event sourcing problems.
Speaker 3: While there are more problems. That's not calling problems so
Speaker 3: challenges of course in this space and kind of if
Speaker 3: you think of about consistency for instance, like eventual consistency
Speaker 3: is a definite thing that you need to think about,
Speaker 3: and also when you think about venture consistency because when
Speaker 3: you're appending an event, there could be well depending on
Speaker 3: your system, but million seconds before the actual projection has
Speaker 3: happened and they read model is consistent.
Speaker 2: Right.
Speaker 3: So one of the things that you need to think
Speaker 3: about then is the UX. How do you deal with
Speaker 3: UX for a good develop user experience for the for
Speaker 3: the end user, well, you want to know when that
Speaker 3: happens so you can actually update the data. So that's
Speaker 3: where the arc part of this story. The second product
Speaker 3: comes in and helps with doing like formalization of commands
Speaker 3: and queries, and you can do like observable queries. So
Speaker 3: instead of having you know, like signal R where you
Speaker 3: have these singular hubs, instead of thinking in those technical
Speaker 3: distrac actions, you basically go in and you just create
Speaker 3: these queries. You can either do it with like ASP
Speaker 3: dot net regular like well gets basically and as long
Speaker 3: as you return an I subject or you have an
Speaker 3: ASYNC numerable that you return, we will automatically interpret that
Speaker 3: as a observable query and add a well either a
Speaker 3: web socket or a service center events endpoint for that automatically.
Speaker 3: And what we then do is we've focused on on
Speaker 3: I guess the biggest framework front and framework in the
Speaker 3: world right now is still React. So what we've done
Speaker 3: is focus on how can we make a good developer
Speaker 3: experience from a dot net back into a react front
Speaker 3: und So we've created then a thing that generates kind
Speaker 3: of boilerplate code to link this up. So then don't
Speaker 3: have to think about the transport, because the transport is
Speaker 3: just an abstraction. Is something that should just be there.
Speaker 3: Whether it's HDDP website, is AHDB two service center events,
Speaker 3: gRPC web or whatever it doesn't really care about, you
Speaker 3: should still be using the same abstraction basically being your queries.
Speaker 1: So when you think you're going to become a real programmer,
Speaker 1: just curious. I mean, the stuff that you're talking about
Speaker 1: here is so advanced from and so out of the
Speaker 1: realm of most you know, forms over data programmers, Like,
Speaker 1: this is real stuff here.
Speaker 3: Thank you.
Speaker 1: That's amazing. I don't think you could vibe code it.
Speaker 2: But I also begs the question like will and LLM
Speaker 2: simplify some of this help you put the right pieces
Speaker 2: in the right place.
Speaker 3: Yeah, So we've been very hard the last year, especially
Speaker 3: as everyone else kind of focused on kind of the
Speaker 3: web coding side of things. How do we how do
Speaker 3: we make this easy to do? In in that sense,
Speaker 3: how do we help developers actually use llms to actually
Speaker 3: build this. So one of the things that we really
Speaker 3: like is the I guess you haven't had Adam dimitric
Speaker 3: on talking about event modeling while yeah, yeah, yeah, So
Speaker 3: we really like that idea. It's a it's a really
Speaker 3: good idea to actually represent software and design software. And
Speaker 3: it brings with it this a whole idea of vertical slices,
Speaker 3: and that is super helpful when we talk about LMS
Speaker 3: being kind of confining the LLLM to these small, tiny,
Speaker 3: very focused vertical slices. And what we do is also
Speaker 3: promote the idea of actually having the front endcode and
Speaker 3: the back end code and the same slice in the
Speaker 3: same folder and actually make it very high cohesive like that.
Speaker 3: And with that and all the stuff that we've done,
Speaker 3: it's like we've created skills and we created instructions and
Speaker 3: all this stuff to make it easier. We can crank
Speaker 3: out really fast with the customer that we're working out
Speaker 3: right now. So it's creating a new feature is super simple.
Speaker 3: And what's also really nice about it is that what's
Speaker 3: different with if you look at like a credit application,
Speaker 3: you basically have like your your nouns in your database.
Speaker 3: But what we have is very clearly named events saying
Speaker 3: something very specific to what kind of state transition is
Speaker 3: represented in the system, and the LMS eat this bide
Speaker 3: up like nothing, right, So it's kind of easier for
Speaker 3: it to actually understand it because they can see the process.
Speaker 2: Yeah, it's declarative, right, it's got the descriptive so the
Speaker 2: tools should be able to grab it.
Speaker 3: Yeah. Absolutely. So we've had great experience with us and
Speaker 3: helped us a lot, but we're doing something new now
Speaker 3: as well because the event modeling is something that we
Speaker 3: really believe in and we're building out this I don't
Speaker 3: know if it's call it a lo code kind of
Speaker 3: thing where you basically it's an editor for event modeling
Speaker 3: where you can actually dragon drop things and you can
Speaker 3: create the flows, the event modeling flows, and basically click
Speaker 3: play and it will be a running application because we
Speaker 3: have we have the engine, and what we're mixing into.
Speaker 1: Is like VB for event sourcing exactly.
Speaker 3: I yeaes VB. It had its place. I did actually
Speaker 3: say that a few years ago to a team at
Speaker 3: a place I worked. It's like if you look at
Speaker 3: VB and if you look at wind forms and later
Speaker 3: what we had with the expression Suite right, Microsoft Expressions.
Speaker 3: What they did there was really really, really great. So
Speaker 3: we lost all that and then years later fakemat comes
Speaker 3: and they're not, in my humble opinion, not even remotely
Speaker 3: close to what we actually lost. So what we want
Speaker 3: to do is kind of well, bring back some of
Speaker 3: the goodness from the old days. Like we have all
Speaker 3: the UI designers and all that, and you can do
Speaker 3: data binding, combine it with the flows where you can
Speaker 3: actually design the commands and the events and the read
Speaker 3: models and all that, and the rules and relationships and whatnot,
Speaker 3: and also on top of that be able to describe
Speaker 3: if you need something very custom you just put a
Speaker 3: description there for the LLM to on top of the
Speaker 3: generated code that we do to actually go in and
Speaker 3: modify and make it exactly how you want it.
Speaker 2: Nice. Yeah, and I could see, well, this whole studio idea,
Speaker 2: it's like half the time you're drawing on the whiteboard
Speaker 2: the event sourcing flow. Anyway, the fact that you have
Speaker 2: a tool that would at least to help you visualize
Speaker 2: and then also implement it's very powerful.
Speaker 3: Yeah. So for us, it's also important that what we
Speaker 3: generate as code, right, so you can.
Speaker 2: Then truth is what you're generating in r truth in
Speaker 2: the code exactly.
Speaker 3: But then the developers can take over or your AI
Speaker 3: or whatever, because then you at least have a starting
Speaker 3: point that's you got there faster and you went down
Speaker 3: the right path more of deterministic because because lms are
Speaker 3: notoriously non deterministic. So yeah, this is a combination of
Speaker 3: deterministic and then AI on top. Right.
Speaker 2: Well, and I've found already with folks that are being
Speaker 2: successful with these tools that the more constraint you put on,
Speaker 2: the better they get. So the idea that you essentially,
Speaker 2: almost from an architectural level, are defining these event workflows
Speaker 2: is setting constraints around the LM to work within those
Speaker 2: architectural rules rather than letting it run roundant exactly.
Speaker 3: Constraints are a good thing actually, so I know, it's totally.
Speaker 2: They're good good for people too, write Like software problems
Speaker 2: get a lot more coherent when you've got a box
Speaker 2: to work.
Speaker 3: In, exactly.
Speaker 1: So constraints liberate Yeah, yeah, you know what you're working in. Yeah.
Speaker 1: So did we talk about versioning?
Speaker 3: No? No, no, So that's another thing that is a
Speaker 3: thing that you need support for. So think of it
Speaker 3: as you already do this if you if you think
Speaker 3: about like anto the framework, you do your EF migrations, right,
Speaker 3: so you have your table and you oh, I need
Speaker 3: to add a column to this table, and you do
Speaker 3: another version. And so what you need to think about
Speaker 3: these things in event sourcing or in general in events
Speaker 3: basically as well, So how do you version that? And
Speaker 3: what it's no different what we've done is basically very
Speaker 3: similar to how you do with antidy framework. You basically
Speaker 3: go in and create this migration like up and downs that says,
Speaker 3: when I'm going from this generation of this event to this,
Speaker 3: I'm going to have, well, this new property, I'm going
Speaker 3: to default the value to this, I'm gonna maybe I
Speaker 3: rename the event or things like this, and you can
Speaker 3: also like merge properties. But what you're doing is you're
Speaker 3: doing it at a much fine grain level, so rather
Speaker 3: than like a table, you're actually doing it on each
Speaker 3: individual event. And the interesting part that we see is
Speaker 3: that most of the time you don't really need these
Speaker 3: things because if there is a change, it's usually because
Speaker 3: you're doing some change to the domain, which means you're
Speaker 3: introducing a new event or you're retiring an event. So
Speaker 3: you stop producing an event. So, because if you get
Speaker 3: to the right level of modeling these events and don't
Speaker 3: fall into a few traps with like credit events types
Speaker 3: of events, you basically end up with these small atomic
Speaker 3: state changes that's going on. And it's not that you
Speaker 3: necessarily need to kind of do these migrations.
Speaker 2: The problem once you do that sort of thing, isn't
Speaker 2: that break replayability. You've introduced a new event requirement or
Speaker 2: you've removed one that's going to be generated in an
Speaker 2: old replay, Like, how do you tolerate that?
Speaker 3: Excellent question, So you're putting me up right, job. So
Speaker 3: of this is actually so when we started designing this
Speaker 3: whole thing, we had to think about these things that
Speaker 3: everything had to be version. So what we do is
Speaker 3: actually when we append an event, we append for every
Speaker 3: version of that event. So that means when we append
Speaker 3: one event, we actually if there are different versions of it,
Speaker 3: we migrate it during appending. So that means if you're
Speaker 3: appending a version three, we will actually downgrade it automatically
Speaker 3: to two and one. And the reason we do this
Speaker 3: is because we want to be backwards and forward compatible, right,
Speaker 3: so we can then be able to actually replay it
Speaker 3: to Let's say you have two different clients using the
Speaker 3: same thing at different levels of versioning of those events,
Speaker 3: you can actually still have those running like think micro
Speaker 3: services or things like this, you can still have them
Speaker 3: running side by side and still be able to produce
Speaker 3: or consume each other's events because of this, So we
Speaker 3: store it version and we just handle it because well,
Speaker 3: of course you might be lagging behind on the migration,
Speaker 3: so we will then migrate on the fly for.
Speaker 2: You sun And of course, again we're talking about real
Speaker 2: life software where you're not always going to have the
Speaker 2: latest version everywhere anyway. Yeah, exactly, so you just you
Speaker 2: might as well build that tolerance in for old versions
Speaker 2: are always going to be around. Arguably, old visions never
Speaker 2: actually go away. You spend any time living on you know,
Speaker 2: generalized message bus with a bunch of you know, different
Speaker 2: groups making tools onto that bus, you quickly figure out
Speaker 2: do not try and synchronized versions. That is the path
Speaker 2: to doom. Tolerate the fact that some the different folks
Speaker 2: are going to upgrade at different times. I got to
Speaker 2: live together, and even when it was a common code,
Speaker 2: I had one where we had a common code base,
Speaker 2: but different administrative teams just weren't going to upgrade at
Speaker 2: the same time, so we could never the possibility of
Speaker 2: retiring a version of anything. You know, like how it
Speaker 2: was one of those things where we're, you know, once
Speaker 2: a quarter we do a report of how many V
Speaker 2: one messages did we still get this quarter? It's like,
Speaker 2: how many quarters of zero before we believe we can
Speaker 2: actually turn this off?
Speaker 3: Yeah, yeah, yeah exactly, And you're basically you don't want
Speaker 3: to have that problem, really, so you want to be
Speaker 3: able to deliver software as fast as possible. So the okay,
Speaker 3: I know there's a kind of upgrading when it comes
Speaker 3: to microservices. People are kind of going away from that
Speaker 3: and talking about modular monoliths and whatnot. But if you
Speaker 3: go back to the idea of actually splitting up software,
Speaker 3: the whole idea behind microservices weren't a technical problem per se.
Speaker 3: It wasn't like, oh, we need to scale. I always
Speaker 3: saw it as a way to deploy software and be
Speaker 3: able to deploy different parts of the software at different cadences. Right,
Speaker 3: So I want to just do that, and if you
Speaker 3: want to accomplish that that this is much easier if
Speaker 3: you actually then go to this level, this fine grain
Speaker 3: level and then have the versioning at this level.
Speaker 2: Yeah, yeah, and have it available a time. We sort
Speaker 2: of came to conclusions like, you know, it doesn't hurt anybody.
Speaker 2: Software that nobody ever runs, you know, like it just
Speaker 2: it didn't matter, right, Like why are we turning that off?
Speaker 2: What are we saving disk space? I got enough disk space, dude,
Speaker 2: Like we'll be okay, right.
Speaker 3: Thanks to big data. Of course, thanks big data too.
Speaker 2: That's what that is. But you know, it was also
Speaker 2: getting to a place where, hey, if an old message
Speaker 2: like that shows up, it's sitting in a queue anyway.
Speaker 2: You don't have to have a V one instance up
Speaker 2: and running. They can wait while you light it up
Speaker 2: and spin it and let it process the message and
Speaker 2: finish its results and then shut off again.
Speaker 1: Yeah, very cool. So do we talk about all the
Speaker 1: parts of Creatus that you want to or I mean
Speaker 1: there's some other things there. Components and tools and documentation?
Speaker 1: Are those the two main thing.
Speaker 2: We're pressing press we pressed against components from the React perspective, Yeah,
Speaker 2: the studio is the cool new I think we're there.
Speaker 3: Yeah, it's uh, that's a fairly.
Speaker 1: Anything else you want to talk about before we sign off?
Speaker 3: Well, I think we've kind of covered the most important bits.
Speaker 3: Of course, there's the devil is in the detail. There's
Speaker 3: a lot of details if you look at your pro
Speaker 3: and the docs there. And but I think if well,
Speaker 3: if people are curious about this, well join our discord.
Speaker 3: We're always there. Uh well, poke me, ask me anything.
Speaker 3: I'm readily available. And yeah, if there's anything wrong with
Speaker 3: our documentation, samples, whatever, we're here to help.
Speaker 1: Awes fantastic Ironer. Thank you very much for joining us
Speaker 1: on dot neir rocks today.
Speaker 3: Well, thank you guys for having me.
Speaker 1: You bet, and we'll talk to you next time on
Speaker 1: dot net drops. Dot net Rocks is brought to you
Speaker 1: by Franklin's Net and produced by Pop Studios, a full
Speaker 1: service audio, video and post production facility located physically in
Speaker 1: New London, Connecticut, and of course in the cloud online
Speaker 1: at pwop dot com. Visit our website at d O
Speaker 1: T N E t R O c k S dot
Speaker 1: com for RSS feeds, downloads, mobile apps, comments, and access
Speaker 1: to the full archives going back to show number one,
Speaker 1: recorded in September two thousand and two. And make sure
Speaker 1: you check out our sponsors. They keep us in business.
Speaker 1: Now go write some code. See you next time. Got
Speaker 1: J Middlevans.
Speaker 2: The summer time that means is home.
Speaker 1: Then my Texes in line resin