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