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, we'll 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. NDC Copenhagen is happening August twenty seventh through the
thirty first. Go to NDC Copenhagen dot com for more information. DC Porto is happening October sixteenth through the twentieth. Go to Dcporto dot com to register and check out the full lineup of conferences at NDC Conferences dot com. Hey there, this is Jeff Fritz, the purple Blazer guy from Microsoft, letting
you in on a little secret about my friend Carl Frank. You know, the guy who started dot net Rocks, the first podcast about dot net in two thousand and two, The guy who's been teaching Blazer on YouTube since twenty twenty. Yeah, that Carl Franklin. Well, Carl's joined up with the folks from CODE in a Castle to teach a week long hands on Blazer class at Are you Ready to Get This? At a castle slash villa in Tuscany. It's sort of a luxury vacation with Blazer learning built in. Carl's calling
it the Blazer master Class. You'll learn Blazer from the ground up, finishing the week with the ability to build and deploy Blazer applications. Since the training happens for only four hours in the morning over six days, you can bring your significant other your partner with you and you should right This part of Italy is absolutely beautiful. There's so much to see and do and and Larry and Marco from Code into Castle are organizing daily activities both at the castle and in
the area. The castle is in the Marema, a less touristed region of Tuscany, offering both classic Tuscan hill country as well as easy access to the Etruscan Riviera, with sublime local food, wine and olive oil around every corner. Breakfast is included every day. There will be two communal dinners at the castle, book ending the experience, and most other meals and all activities are included. And did I mention you'll learn Blazer in person from Carl Franklin.
Listen, space is limited, and for very good reason. This is quality training in a beautiful setting. Go to code in Acastle dot com slash Blazer twenty twenty three that's bla z R two zero two three to take advantage of this amazing opportunity to join Carl in Tuscany for an unforgettable week of led dulce vita while advancing your programming skills in this important new technology. Hey, it's dot net Rocks. I'm Carl Franklin, and I'm Richard Campbell, and Jeremy
Miller is here with us. We'll talk to him in a few seconds. But first, Hey, buddy, how's it going. I'm slightly wounded. No really, what happened? You know, we're we're getting close to moving, and so the neighbors for his little party last night, and I may have pulled out a twenty one year old bottle of whiskey and somehow the whole thing disappeared. Oh my god. So uh, you know, neighbors. The toughest part of leaving this house is the neighborhood. I got that because
you always talked fondly of your neighborhood parties, and that's just nice. I have. I have neighbors on one side that I like, the rest of them across the street from me doesn't speak English, and the one Candywompus across the street, I'd rather not talk to him. So just one of those things, right, It's just one of those things. Well, anyway, let's roll the crazy music for better No framework awesome. Well, what I have is episode ninety seven of Blazer Train, which is coming out today as
we speak. You're staring one hundred in the face. Brother, almost yeah, but this one's important because there's no code demos. It's a conceptual overview of Blazer and dot Net eight and I won't basically the mantra is it changes everything, and I won't tell you what it is yet. You got to watch it. But I had this revelation while, you know, the first
time I was talking about they were talking about Blazer United and stuff. They're talking a lot of features that didn't have anything to do with interactivity, and then I realized, that's a good thing. They've added stuff to Blazer that asp net Core NBC has been doing, but now you can do it with Blazer components and it doesn't require any you know, any server side signal er
or circuits or anything like that. They're just features. So I think, you know, with the new interactivity stuff being dynamic and you can choose it, plus these these features of existing stuff that now now Blazer, the Blazer web app template in dot net eight becomes your go to ASP net core project type template because because there's no reason not to. Right anyway, I just blew my mind sort of a Blazer grows up moment. Yeah, it really
is. And you know that this is where Microsoft is putting their effort into. You know, these Blazer components are great. You don't have to do interactivity, you don't have to do web assembly, you don't have to do Blazer server ken if you want to, but you don't have to. Right, it just changes everything. So anyway, check it out. No, it learned it, Levet. This is episode eighteen sixty, So if you go to eighteen sixty dot poop dot me, you can go right to the
video or go to blazer train dot com look for episode ninety seven. That's it awesome. Who's talking to us today. Richard grab comment off of show eighteen twenty three, the one we did with one Jeremy miller Hey talking a bit about Wolverine, dot net and command and Message bus. I had a lot of comments on this show. I mostly about Jeremy's rant at the end of the show, which was hilarious. It was great. Yeah, look, maybe a touch hyperbolic, so the literalists had a little problem with it.
Yeah, and rack Yak says, this is a great episode, and I was amused by Jeremy's rant at the end. I feel like he might have missed the mark a bit there. In my experience, the prime benefits of clean Onion style architecture do not really pertain to the horizontal, so to speak. I've worked in several such systems, and I can show you that
the vertical thinking was still very much the norm on all of them. Sure, by throwing a repository interface, which is by the way, not prescribed and clean, in front of the data access, you leave the door open to swapping underlying providers and data stores. But honestly, whoever does that? Rather, the prime benefit of clean in my experience, comes from just abstracting away infrastructure and out of process details like databases and messacues. Something that clean
does prescribe. Doing so promotes isolation of core domain logic, and that process is hugely facilitates automated testing of that logic, which is where I've reaped the greatest benefits. Yeah, that's fine. I'm not going to disagree for a moment with you know, Jeremy's core purpose, which was you can over engineer, you can turn architecture into dogma, and that doesn't necessarily serve in delivering
software. But you know, to Rack gass point, there are textual styles that certainly support making software more testable, and yep, testable software is more reliable. Yeah, yeah, so, Rack yak, thank you so much for your comment, and a coffee. Music cod By is on its way to UNI if you'd like him a cofee of music code By, write a comment on the website at dot net rocks dot com or on the facebooks.
We publish every show there, and if you comment there and I reading the show, we'll send you a copy of music go By and you can follow us on X if you want. I can't believe I just said that. Why Why why? X? He's everybody knows, you know, he's not like anybody's confused when you say Twitter, Right, let's take a great brand and change it. I just don't get Apparently he's auctioned off all the last of the logo stuff. You can buy the big sign off the front of
the building and things. Anyway. You can follow us there Twitter is what I'm talking about. Or on mastodon. I'm Carl Franklin at tech Hub dot social and I'm Rich Campbell at mastadon do social. Send us a two let us know you're out there, and let's bring on Jeremy Miller for like the I don't know ninth time he's been on a long time. He gets around. Yeah. So Jeremy Miller started his career as a real engineer and that's
in quotes, but wandered into software because that looked like more fun. Since then, Jeremy has worked in and led software development teams in the computer manufacturing
industry, finance, insurance, healthcare, and banking industries. Lately, Jeremy has been focused on leading software architecture teams and helping mentor other software architects, having had roles both as an in house software architect and as a software consultant, Jeremy has a great deal of insight into the challenges that confront companies developing
and maintaining enterprise systems over time. Jeremy is well known for his open source software tools, starting with structure Map and continuing today to Martin and Wolverine, also known as the Critter Stack, which we'll talk about. Jeremy is also a frequent author and technical speaker at software conferences and can be found at Jeremy dmiller dot com. Welcome back, buddy, Hey guys, glad to be
back. Just kind of point out if you're really all the way up to episode eighteen sixty, you understand that puts us right on the verge of the Civil War. Yeah, right on, one more episode and it's Civil war time. And sorry for the long winded bio. I remembered you were going to have to read that out. It's like when your kids want you to read a book that is just the most awkward thing in the entire world to
read. Right, let's read Robinson Crusoe. Yeah. Okay, So I don't know if anyone else to remember this as a kid, but there are the Lloyd Alexander series the I think Pridane books. No, I don't remember those we read as kids, so it's a fantasy series. It went all kinds of Newberry Awards for kids, and I loved it as kids. The
Black Cauldron. Disney made a movie out of it. Okay, yeah, yeah, yeah, But it's all based on Welsh Welsh myths and mythology, so all the names are will Welsh Smith's and apologies to any Welsh speakers, they are a little hard to pronounce. Some weird consonants in there in places where they promise shouldn't be yea, yeah, well if you have a comment on the comment, I do. So he's right in the sense that that you can be okay with clean or onion or all that kind of stuff if
you focus on vertical slices first, keeping the places. And I did an entire conference talk at in dc Oslo this year the contrarian view of software architecture. Right. Where all these these prescriptive layered architectures go wrong, It's because people follow them, maybe a little bit naively, but they build these massively horizontal layers where you still have this massive project where every single feature is spread out on these four or five layers. You can't follow the code at all.
You can't upgrade anything because each individual layer is just too big. It is impractical to reap any of the theoretical supposed benefits of clean architecture and whatnot. Yeah, so I'm gonna stand by that rant. I've even got a whole talk about it now on online. It's a good rant. Well what you've been working on. So, at the tender age of forty nine, I have gone solo. So founded a company called jasper FFX Software. It's based named after my little hometown back home, map dot on a blacktop.
But we should disambiguate jasper FFX, the company with jasper ffx the product that is now Wolverine. Right. Well, so somewhere another there's like an old recommendation to don't name no damn your product after your company. Yeah, and so jasper was going nowhere we renamed it. Somebody said, having a conversation with my other contributors on core MC team member for Martin of you know, hey, what if we call it Wolverine. It's the same family as Martin.
You know. Somebody started laughing and calling the critter Stack our buddy killed from from jet brains just you know, in thirty seconds just popped up. Here's the possible graphics and emblem for it. So critter stack was born. I love creatter stack. That's cool. Yeah, it's a lot more fun. You could be critters inc. You know, yes, yes, yeah, all right, So it's called Jasper Effects. So is it based on
services around your products? I guess and consultations? So you know, obviously this is very topical because of all the conversations going on in lieu of the mock incident. We're gonna throw spaghetti up against the wall, right, We're
gonna start. We are already started as a services model. We're helping a couple of clients with Wolverine specifically, but we're hoping to grow into both the services and a full blown product company service contracts, consulting of course, but we are going to build licensed to add on models to Martin and Wolverine, specifically for bigger companies and need big volumes of data. Right, sure, so you're sort of taking the identity server model route. It sounds like,
yes. So we're very conscious of what do enda software is done. You know, we don't start from as anywhere near as big user base as they did, so we're going to try to stay with an MIT licensed open core but build commercial products on top. Yeah. You know, we've we've kicked around the idea of going to the Business Business Software License maybe at some point, but right now open core. Did you Your listeners will know that's very
controversial. How do you take an open source project and take it sustainable with without managing to aggravate the hell out of your users? Yeah? Yeah, that's been a topic of many of our shows. Yeah, it's you know this. We have this story arc of the evolution of open source going on in docmond Rocks, and certainly we've had great conversation different folks, including the de Ende folks, about how they're how they're trying to make a living as
well as support their customers properly because it's also impediments there. But the nature of their product as an identity product, very enterprise centric, was genuinely enterprises just plain old one to pay for it. I almost been paying attention to
Troy Hunt's battles with things like like the have I been pooned API? He's charging like five bucks for it, but the barrier to pay that five dollars for most organizations like it's got nothing to do with the money, has to do with the workflow, like what does it take to get a bill paid essentially inside of a company. It's it's just fascinating to me that we struggle with this in software to this day. So you know, I'm still very
early in the journey how to get how to monetize things. I don't know. I am just paying right now. We're paying attention to everyone else, you know, dinga going first, definitely watching particular software. Just there's just a small handful of open source companies in the dot net world, and we're hoping to be one of them. But I don't I don't have those answers yet. Yeah, we haven't made it. We haven't made it. I don't think we will make a show about this situation with Mack. It's we're
in the middle of it right now while we're recording the show. Do you have a comment on it? Well, first of all, people need to know what happened, right, they took a dependency on something that was sharing data, right, So I'll try so folks, I and guys. Honestly, I probably wouldn't have reached out to be on the show if i'd known that what's going to happen. So, you know, mock you is you actually used I was. I don't use it personally. I prefer in substitute
and other options. But it's massively used, right framework for those of you don't, yeah, sorry, you know, And it's there's a long history, so it's been around a long time. It is. The download numbers he quoted online and kind of shocked me. Those were big. So it's very widely used, you know, And as far as I know, it's just just Daniel. It's probably the only guy that's really managing it. So he has worked up this other small library that as a way to try to
gather up support. It was going to try to gather up if you were using the library. It was going to try to look in assuming it get you were going to get repository. It was going to try and find email emails from contributors from the get history and it emailed it back, It sent that back to some kind of central phoned home, right. You know. I think it was a well meant attempt to just figure out who's using my tool, and I can build an email list and I can send them out
and hey, do you you're using this, you're getting value. Kid, You want to do you want to support it? You know the problem He did tell people about this ahead of time, but you don't really get feedback on that kind of thing until people get impacted. But when people started understanding, hey, this is sending information back, you know, there's privacy concerns.
People start talking about the European privacy. I started paying attention to it when somebody said mocking library compromising pa, you know, potentially sensitive information that that's the first time I started wondering what is going on here. So that's my understanding of what's happening, and the the the reaction has been pretty harsh from the community game Yeah, I mean at the moment again, I don't we don't do you know, daily shows here read real time, so it's
unfair to public. Were published this a few weeks later, but you know today on Twitter you've got smart people in software saying everybody makes a mistake like be kind, you know, which I think is a good policy, Like in general, it would have been worse if he shared it with you know, or sold that data, I think, but if if he's using it for his own personal email list, to say hey, thank you for using my stuff or whatever. It's not it's a little more benign than than sharing
everything. Still not cool. No, tips, I think he's back. He's back that out. Let's give it a bit of about that. He's going to take care of the privacy concerns, So get on the right side of those kinds of issues. I'm gonna say, I don't think you should have done it exactly the way he did it. But on the other hand, he's apparently gained empty new GitHub sponsors, so maybe in this particular case
there there's a happy ending for him. But it's bringing to light all the normal issues about how how is open source is going to be maintainable and sustainable here when so many of us depend on it in our jobs. Sure, yeah, you can't just act as if you're a business and you've got a user agreement and yeah, so anyway, no, I mean he was he didn't experiment. Again, we can debate the methodology, but I understand it. It's and it's funny to see that what it did get generate with a
whole bunch of new sponsors. So anyway, I don't I won't. I want to show this as a strategy, right, It's just like, yeah, I hope it doesn't happen to you. I mann create controversy, controversy, get money. Yeah, I don't know if I want that system that
either, all right, man, I know of mock. I don't know that I have it in any projects at the moment, I understand the situation's got into it seems unfortunate, and I don't know that will where it'll go from here, whether it's becomes a talking point going forward in this larger story of how we make a living on our open source projects. So, on another topic, what's new with Wolverine A lot. So it's made it post just since we last talked. It's made it post one. It's made it
to the big one point zero. You know. It's the usage numbers aren't off the chart, but it's enough that I'm busy every day answering questions on discord. Start to work with some initial initial clients that are implementing it right now. About to push a lot of improvements for as your Service bus integration. We've pushed Sequel server, a new Sequel server back transport for people that
want to do messaging. They already have a sequel server database. They don't want to invest in other infrastructure trying to drive It also has a model to build HP point points that would be an alternative to a minimal API or MVC for web services that was specifically meant for originally for Hey, you're using Wolverine, you might as well pull this in because you'll need when you're integrating with Wolverine, you're gonna want to use transactional outboxes. There's a very strong middleware
approach. And it turns out I think the HP service model is starting to catch on because it's it's lower ceremony code ceremony than VC. I think we have the potential to beat minimal API and MVC by quite a bit with performance as well, just by having a lighter weight, just letter weight runtime. So I'm real happy with how it's going. And to circle back, so some things that have changed significantly since the last time we talked that kind of
surprised me. It has through a lot of early user suggestions that I'm glad I listened to. It's kind of gone off into kind of a quasi functional programming approach. I'm gonna take a lot of online from f sharp driving to a point where I think Wolverine. Using Wolverine is going to allow you to get to a very maintainable code base with very low code ceremony, without deal
having to pull in really complicated clean architecture onion architecture. Whatnot? Being able to do more doesn't use affluent syntax for example, no functional decomposition a little more much more more conventional based, but being able to break a break a single handler, single message based. Start organizing our code around use cases rather than nouns. Being able to put very cleanly put your data, access the actual business logic, and supposed processing handling all in one file, but still
have very clean separation of concerns. Just you have far fewer coding archifacts. All the related code is together in one place, all the testability you want. Put closely related code together, minimal abstractions, don't scatter your code all around a prescriptive, clean architecture project structural Well that sounds great. So why did you WinCE when you said the word functional? I have gotten into it quite a few times online. The the f sharp community can be very enthusiastic.
Oh come on, you can say it better way than that. Do you all remember decades ago on Silent Life, there was a skit with Pat Sir Patrick Stewart, Yeah, the if it's not Scottish it's crap. Oh yeah yeah, and Mike Myers. Yeah to me, the F sharp folks there there, Sir Patrick, stupid little dogmatic. I mean, if it's not their way, it's crap and that that can rub me the wrong way sometimes. But Wolverine is probably turning out. I think it's probably turning out
to be eventually very sharp friendly. It is going to allow C sharp developers to maybe write code a little bit more functionally. Oh that's good. That's certainly. That's certainly a show we've done as well, right, that that you learn learning a functional language helps you write more functionally in other languages as well. I don't know that I necessarily pointed the F sharp folks as the dogmatic ones. Folks that like functional because it's not the most popular way to
write code in the world. They tend to be very enthusiastic about doing that, Like you don't write functionally by accident. Yeah, that's true, Richard, that's well said. I don't think. I don't think I've done sime as dogmatic. I didn't say dogmatic, said I did, so I'll take that one. But but but if folks can also you know, whenever you talk to a smaller community like that, like they're there for a reason. Yeah, there tends to be a higher intensity in general the way they approach
their language and programming styles. And they probably worked pretty darn hard to get good at it too, you know. Yes, yes, functioning is functional is challenging way to think in two ways about it. But just to follow up on that just a little bit, so a crucial difference between Wolverine and
it's natural competitors, the mediator and service bus mass transit. I'm going to leave some out, sorry, folks, brighter for me and Cooper Rebus, they're all they generally follow pattern I prefer to as the eye handler of t approach. You know, sooner or later there is some interface you have to implement that has a couple couple generic constraints for what's the input type? Right, you have to conform to their model. Wolverine instead wraps code around we
wrap or adapt or around your code. Okay, the sounds a little abstract. As with inheritance model, it's doing runtime code generation code great it's not as crazy as it sounds, but it enables us to do a lot of things like out of your handler methods or your web service methods, you can return an object that just says I want this document saved, I want this file saved. So one of the things that destory or I want this other message sent out. My message I'm going to decide what gets done next,
doesn't go to this web service that web service. How does it continue? But you're just returning a value. Your handler functions become pure functions. They don't have to be asynchronous anymore. They just return, take in data, return data for what's going to happen. In some cases that's great. Actually, the more I don't have to modify my code to suit a transport, the better. Yes, that's that's our theory, and that's our hope. That some people are going to hate it, but we just hope that enough
people love it that we have a viable path forward. Yeah, And you know it's funny how much there you have these thoughts about using this path of success or you know, falling into the pit of success approach to if we use the tool this way, like just good things are going to happen, and that's very hard to do. It's very very hard as a tool company.
It's really the only way to get it's the goal, but the only way to get there is to get it out used by enough people that you get feedback on all the things that are confusing or the ways that they use it that you didn't anticipate in it's kind of a long term sand paper approach. You know, they find all the rough spots in your system, everything that's confusing, and you're just constantly standing off off that. So but at the same time, you still want to stick to a path, right,
Like you don't want to be all things to all people. This is kind of an opinion approach to building software. So you know, it's a it's a question of it is that a rough edge or is it the wrong way? Yes? And so far. You know, again, it's not a huge amount of usage. I don't know if it'll ever go mainstream, but some people that are into it have really liked it and even seem to prefer it over the older eye handler of t approach. Hey, if it delivers
results, right, that's what people care about. Yes, and gentlemen, I use that term loosely. I'm gonna interrupt for one moment for this very important message, and we're back. It's dot net Rock. I'm Richer Campbell. Let's call Franklin. Hey, Hey, chatting with our friend Jeremy Millner a bit about his new re organization and reorganization for Martin Wolverine, the Jasper FX folks, and just this idea of how approaching software. I'm not gonna
say from a less formal style, but you know, lightweight. I think you should call it critter style. Serious. We're definitely aiming for the lowest, for a very low ceremony code style, right that that also leans towards and I'm thinking about conversations we've had recently towards this mindset of small teams, and a lot of these ceremony ceremonious approaches to software are built around the mindset of we have a large number people that we want to work simultaneously, and
so the ceremonies actually a way to keep those folks in line. But if your team's not that big and everybody can fit around a table for dinner, then then stay in low ceremony makes a lot of sense. You get more delivered in less time. So maybe taking a tangent from what you're saying, going to the topic of microservices, which I know we're in a full blown backlash against micro services. Yes, the pendulum has swung. Yeah, we're
in the trough of the disillusionment. So what I am seeing is some efforts, some attempts to adopt microservices are defeated because they still try to adopt a full, big bang, clean architecture approach of Yeah, this thing is technically very small, it could be, but I'm still going to use four different
projects. I'm gonna layer do a bunch of layering. I have all the exact same overhead to get all the extra stuff in there to write just a tiny bit of functionality, and that's defeating the purpose of using a microservice. So I think the pendulum is going to correct just a tiny bit. Yeah, I think so, I hope so at tiny bit. Yeah, it's
it's going to come back a little bit. But the microservices thing is going to work if you can just write much simpler code where you can see everything together and stin stay in the arena of I'm also going to try to pick purposely picked tools that play very nicely in Integration testing kind of another theory,
and this is something Wolverine and Martin especially you're built on. Is the idea if you can make I think, if you can make integration testing easy all the way end through the database or through the messaging with Wolverine, if you can do that, then I think you worry much less about abstractions and malch libraries and all this extra stuff. If it's still easy to test your code, I don't worry quite so much about splitting that stuff up with that extra
extra stuff just to get get unitestine. So it's another way of driving towards simpler code. Yeah. Absolutely. Wait, you use the term tropic disillusionment, which is from the Gartner hype cycle. It's funny because I've been using it on Windows weekly lately to talk about large language models. Right it's like h's changed everything. It's always like we are at the height of a hype
cycle right now. Boys, Let's be clear, you know you're not more you could never be more deluded than we could possibly be about this technology right now. All the noise that's going on, but just the you know, it's not just up and then down, it's coming you come back up again. Right. The gardener folks call it the slope of enlightenment to you climb out of the tropic disillusionment with it. There is this oscillation overreacting both ways
before you start of settle into a sort of reasonable productive approach. Right, Anything that's parabolic is ultimately going to come back, Yeah, come back down. Yeah, I'm wear or the other. I'm sorry. I did have this queue up because I knew we were going to have to talk about the mock cue situation. Yeah. So one of the a thread common thread I see going on what's left of whatever Twitter is called now and Mastodon is why
are you using mach libraries? You should never be using moch libraries. So two things would be true here. Huh, folks, You mugously overuse mach libraries in ways that makes their tests very brittle, very slow, extremely hard to understand. I've I have probably caused that younger in my career, and I have tried in vain to help teams get out of that situation. But at the same time, there's absolutely some very valid usage for these mock libraries,
like mock you or in substitute. So don't don't throw the baby out with the bathwater. I call these things they're kind of rip pepper appropriate pepper flakes approaches. You know, a little bit can be good, a lot is probably always going to be bad. So don't don't swing guardrail the guardrail of you know, we're way over using it now, they're always bad. Throw it out all together. Well, there's a there's a couple of silos
and scenarios that really you do need mocks. You know, when you're doing communication with something that costs money and you don't want your tests to rack up a lot of bills, and it's relatively simple data, throw a mock in there. You know, there are some situations where it makes absolute sense. It does right now. Some people are gonna argue with you as well that you would just use some kind of static hand rolled fake fake, and and
that's that's valid too. But there's there's absolutely places I would want to use a mocking library for testing, collaboration or interactions. Yeah. Yeah, but all things can be overused, and yep, we're better worth. I think our industry is prone to overuse, you know, I think like I think we struggle enough with tools that once we get good at when we try to use it, for a lot of things. It's like you get your you get your head around a mocking library, like I will not mock all the
things. Yeah, and I helped. I helped cause some of that that that was Jeremy clearly I've seen I've seen it go very badly. Yeah, but yes, I helped cause cause that with structure Map had an automocker that that made it way too easy to use use us kind of tools, and folks ran with it. Yeah. I think that if you just inserted more pain into your into your your software, it made it more painful to use.
That's the way to go, because then people won't use it, and that's what you want, right, and it's you're laughing, but that's an argument we really had over automocking tools ten fifteen years ago. Yeah, that you it's better for everybody if we make it a little more painful, so people notice when things are off the rails. Right, you're gonna put up in in the I D eight. Are you sure you want to do this? Is that really the answer too? But yeah, you know, we
live living in the Microsoft space. Microsoft is famous for the very gradual level of education you can get in early not no much get some results. There are plenty of other tools out there that have high cliffs where you've got to you've got to look quite a bit before you know. Compile one works and you get somewhere, and there's a trade to that. You end up with
a much more gradient range of skills with these easy entry tools. And although you know, you find someone you know who's who's effective in a challenging language. And I'm that you can pointed F sharp, Like, if you can get cod out the door with F sharp, you probably know quite a bit
because getting good at that isn't trivial. Yeah, you know, I had bet too it would be easier if you started with F sharp versus going through you know, I don't think people really do a lot of oo oh yeah with C sharp, but you know, starting with a class oriented language like like C sharp or chava. Oh yeah. The unlearning effect is very interesting. You know, if if the first line programming languages you ever learned are
functional, you just that's the way you're gonna think. Switching between those thought processes is that's tough, yeah, or from our generation of folks, I know, I'm a little younger than you are, but our generation of folks learning very database intensive programming first. Yeah, I think it. You know, what was the terrible saying that if you learned basic first, you can never learn to be a real developer, getting people to move beyond between off
of being a very database centric developer. That's something folks used to struggle with. Yeah, because that depends on what area you're from as to what were you learning and why were you learning it? Right, If you came into software development in the client server time, that's you were doing the same data modeling approach over and over and over again. We were speaking directly to databases.
Everybody wrote a little sequel like that was just the world as it stood at that time, And it is interesting you to think about how much of your original coding mind is shaped. Then it's true taking that as a tangent, because I refuse to let this go going back to picking on cleaner onion architectures. A lot of the prescriptive guidance you see from those things, people very naturally, I think, use very crud centric examples. You know,
here's the to do or I haven't. We're going to do something about invoicing, so I have an invoice controller and everything that touches an invoice, goes through an invoice control or an invoice service, an invoice repository. That kind of noun based code organization is where bigger apps go terribly wrong, with clean
or onion or anything like that. I see several other people they're starting to talk about this a little bit more, and I'm jumping on this bandwagon, moving toward organizing more around use cases or the message messages or inputs and operations, you know, the vertical slice architecture idea. Can you explain what you mean by noun based, like what kinds of nouns are you seeing? People?
Yeah, So, in a creud centric work view of the world or really a data centric view of the world, I have Let's say I use an invoice because it's soason a lame. Everybody has an invoicing system somewhere, so I would have an invoice controller that may have get post put for modifying an invoice, and if it gets bigger, it probably gets a lot of extra operations for approve the invoice, you know, so on and so forth.
But I am first organizing the code of anything that touches an invoice goes in these big these files invoice controller to service layer to the invoice repository, and you can very if you're not careful. And this happens all the time, these classes, these horizontal layers for an invoice get very bloated. That that's kind of a noun centric view of I am organizing code based on it's
data storage or how this relates to an entity. Now, So the entity now and would be invoice in this case, Yes, I got it. So in that vertical slice architecture, I think that's that's Jimmy Bogart's terminology. People, I think I like the terminology, you know. Instead, I want to organize, and other people describe it. I want to organize around the verbs. What I would say is you want to organize around the use case a message. Say I want to organize code around approving an invoice.
So in one file or one one namespace, I'm going to have the DTOs that that model the message for the approve invoice. Yeah, I'm going to put any kind of any kind of data access business logic that's specific to that use case goes right there, you know, And there's all kinds of racoles. If it's shared logic, then it doesn't go there. But anything that has to do with that particular use case, I'm going to put it together right there in a tight area of code. I still want separation concerns.
And also, you're not you not building a slice for approving everything. It's just approving an invoice. Yes, so it's more granular. Yes, But just think of all the times you're in one of these big, very very large systems and there's some kind of problem and you're trying to troubleshoot what's wrong. Right, You're not reasoning about your data layer, You're reasoning about the
vertical pipe of how does this message turn into whatever it does? Yeah, like putting all the code for that one message as close together as possible, I think you've got a better chance at being able to unwind what's going on. Yeah, it makes sense. It means I find this fascinating, Like we're really kind of talking about a minimal approach here. One of my issues with vertical slicing the vertical slice approach then is is also you've got this Conway's
law effect. You now have a piece of code that works that's kind of end end. I think you're prone to hanging more things off of it than you probably make you you should like at some point you're just sticking stuff there because it's easy to add it rather than make a new slice. Right, Yes, yes, so I'm gonna take that one as well. So I've been preaching a little bit about coat ceremony and sorry, folks were going on a little bit of a trip. My furry four legged coworker really desperately wants
to come in. Oh yeah, that's okay. The other thing that strikes me is that once you've got a working vertical slice, it's somewhat you know, the Conway's law fact comes into play off. That's that you know you've got as system that works, so you're going to tend to reflect it. I suspect you started hanging features off of it that maybe should be in a different slice, because the commit to building another slice is pretty high compared to well, I'll just stick it in the slice to work. Yeah. Yes,
so that's a great point. So let's let's dive back in get again into that theme of trying to go for lower ceremony code, because what you're talking about, that's something I have really seen be a huge problem in big enterprise systems that they just accumulate code as client A wants this, client B wants a special logic, and you get these very bloated controllers, message handlers, whatnot, so code ceremony, and you think of that is, how
many mandatory steps do I have to take to split something off? Do I have to add four five different classes to do it? Do I have to go to up team different projects? Do I have to map something? Or can I just kind of pop something off in one file and do it very lightly mandatory steps? For do I have to explicitly code up new authorization rules. I've seen that kind of splitting you're talking about. I've seen it defeated
by mandatory instrumentation. Like if you're doing hopefully your framework handles things like open telemetry, emitting and air handling, air handling and logging for you like Wolverine
does. But if you're not, if you're doing that manually, where you're saying the developers have these rules of you shall always write this log statement, you have to error explicitly handle errors this way that is going to add so much overhead that you will tend to not split features and those slices up, and that will lead to bad code So what you're saying is in a plug for Wolvertine ra RA, which is cool. But what you're saying is because
Wolverine doesn't inject its impede or impose you to redo your stuff. Like it sounds like you have air handlers around this stuff that you're calling, so you don't have to do that. You have logging around the stuff that you're calling. Yes, And you know, in another sense, Wolverine is that way
because of the experiences I've seen with enterprise systems. Yeah, the where they had higher ceremony coding models, try trying to take care of things like like instrumentation, insecurity or was great examples you want at this point, you want to open telemetry on everything these days, and it's really nice if it's just done for you, so developers don't have to think about it, right, But you don't necessarily want to do that at the stack level or the slice
level. Rather, yes, or that. That's that's how I feel about. Well, yeah, you used to have to roll this stuff, you used to have to build those horizontal pieces. But I mean, I think it's this is your to your point, It's like these are solved problems, just use them. Right, yes, and to go back to to here to really put this in perspective for younger folks. So I started my first serious software development it was Oracle PLC quel, but then it was Visual Basic.
Yeah and yeah, so VB six didn't have stack traces. You know, younger folks are horrified at this idea that they didn't exist. You would manually in every single method, every single fuck and you would have a little bit of on hair or something. You would manually build up a stack tress
yourself in every single method to make this happen. This is a rule I enforced on my team because web programmers didn't write bugs, so why would we need a snack but here that bloated the size of your code to the point where you didn't want to break things up or sorry, Richard, maybe to go to your generation, Cobalt developers nice things. So we are at the same age. You know, if you've worked around Cobal developers. I used to say, I can look at code in any language and tell you that
was a Cobal developer. So there was a very serious penalty, performance penalty for pulling out a separate method or a separate function. Yeah, so if you look at Cobalt. Quote they were taught, Yeah, they were taught. They would have these massive pay up on page functions that were bigger than anything you've ever seen before because they had an incentive to do that way.
And just how awful that is to deal with. Yeah, I argued that the object orientation won back in the eighties because it utilized the computing resources more effectively. At the time, that manipulating a given area of memory that you were calling an object was more resource efficient than the tendency of functional to do copies of things in memory. Call for immutability. You know, we'd like immutability from making more reliable software, but it used more process or to use
more memory, and at the time those were constraints. They aren't anymore. You know, today we have enough memory and compute that we could afford to make more reliable software using these techniques than what was necessary in the eighties with the single core memory restrictive machines we were using. It's not my fault, man happy, We're just trying to write. I had to do it that
way, that's all it was. Shall we talk about No, we're not kind of talk about it, but I might bring up the memory of on error resume next, which means, hey, if there's an error, I don't want to know about it, just keep going. It'll be fine. Everything fine. So I the first thing I ever did professionally, when I was still a real engineer, I wrote an ASP classic system on access ninety seven from my engineering shop. It was great fun, but I just remember,
hey, if you sprinkle this on error resume next thing everywhere. Thanks, just work, Thanks, just work. It's awesome. It's crazy. And then, of course, you know this first system, it became successful enough that other people in my engineering group started using it until we start discovering no values in the database. Where did this come from? I don't know. It seems to be working. Well, it's it's worse than that.
I I was running this on my just my compact desktop and I came in one morning on a Friday morning and this heard this terrible clicking sound where it was using my machine so hard it threw a head through the hard job. All right. But and so everybody's using this system now, and it's like Jeremy when you're gonna get it up, uh my boss at the time, or somebody from the real it people. Because I was a shadow it. Okay, so Jeremy, where is this in source control and we'll help standard
up for you on on a real server. And I looked at bat him and I asked, what source control? Yeah? Yeah, well, and I feel like the power platform stuff that's that's hot at the moment is a new generation of new developers. Yeah. You know, they're their domain experts who are trying to get things done and they're using these tools. And I see that same sort of reaction of you know, quote unquote real developers making fun of them. Oh, I'm like, that's not wise. But they
have to learn all these things too, you know. Over on the on the run as side of my life, I'm talking to administrators about we're going to need to give these guys governance. Yeah, they give them some guardrails, make sure they follow the permission rules. You know, the same thing they at that that piece of software is be stufs. When more people are using it, let's get it out of the personal account of that person and
into an administered system. Like you know, that's the reality of solving things. But more importantly, it's just acknowledging we're never getting to the bottom of our to do list. Ever, like that's not a thing. So anything that'll take a few more things off the to do list is a good day. Have you done any major updates to Martin speaking of you know, the current state of your creator software. It's coming so oscar oscar Nex has mostly
been dealing with things. It's been a ton of there's just bug fixing never ends, you know, dealing with new dot net versions. What is coming up for Martin is, you know, I'm making We're making a big run at revamping the link provider. Link link Provider. It's just it's ultimate permutation.
Hell, so we're taking another stab at it. But also trying you know, we did have a very serious contribution come in sponsoring link improvements, so I'm trying to trying to get that folks, those folks their improvements, trying to make it a lot faster after that. It is a lot of it's actually gonna be a lot of integration with Martin and Wolverine. First class subscriptions, you know, the ability to stream data out of Martin, whether
that's to cough or something else. And then the big thing which I probably talked about the last time I was here, but this is our our this will be our paid a model of being able to distribute work across multiple nodes in a big cluster, whether it's multi tenancy, moving tenants around, but finding ways to scale up Martin and specifically that a sinkers projection work you have to do with with event sourcing, to be able to spread that load over
different nodes and maybe even dynamically bring things up and down elastically. That'll be our paid model. That that's something we hope to get started. Well, we we've already put some work into it, but that's that's the subscriptions, scalability, link improvements, that's where we're going next. I think with Martin, maybe next year we try to branch out. We might try to branch out into other non dot net platforms. Yeah, I don't know what that
would mean yet, but that that's that's longer term. I find it fascinating that, you know, you have folks that come at you with, hey, we really want this feature. How do we support you to to get this feature done? And sometimes that's a monetary compensation. Sometimes yes, I mean that's that is interesting. And if anyone's listening, bar the Shingle is open, We're open for business. We've already done custom, custom feature work
inside of Wolverine and Martin hit us up. Sure. Well, what I appreciate about this conversation and about you and your products is that your products have your experience and wisdom built into them, and that's very clear, So I have no problem recommending them. I appreciate them. Yeah, and thanks for thanks for being with us. It's been great. Hey guys, thanks for having me yet again. All right, and we'll see you next time on
dot net rocks. Dot net rocks is brought to you by Franklin's Net and produce by PLoP 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 ocks 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. Ban