Bèr Kessels is an experienced web developer with a great passion for technology and Open Source. He joins the show to talk about his article, "How do I test X" is almost always answered with "by controlling X". He explains his article, how testing works, and many more!

Charles Max Wood (00:01.55)
Hey, welcome back to another episode of the Ruby Rogues Podcast. This week on our panel we have Valentino Stoll.

Valentino (00:09.57)
Hey now.

Charles Max Wood (00:11.366)
I'm Charles Max Wood from Top End Devs. We have a special guest this week, and that is Bear, Kessel's Bear. Do you wanna say hi, introduce yourself, tell us where you're from, why you're famous, all that stuff?

Bèr Kessels (00:24.23)
Yeah, I'm Bear. I'm from the Netherlands. I also live in the Netherlands. I'm a Ruby developer for I think something like 12, maybe 15 years, quite long. Rails mostly. And yeah, I wrote some articles on my blog. I'm blogging a lot. And I'm really big into testing. So that's basically me.

Charles Max Wood (00:52.07)
Cool, yeah, we're gonna talk about testing here. We were also talking before the show about having you come back and talk about the Fediverse. So if people are interested in that, that'd be a fun one to get into. But since we invited you to talk about testing and you prepped for that, we're gonna roll with that. Now, just to kind of dive in and kind of get things rolling, the article that we reached out to you about, and it was kind of interesting.

I think there's a lot more to be said than what you can get into a reasonable blog post about this, but you said, how do I test X is almost always answered with by controlling X. So do you want to just kind of give us an overview of what you mean by that?

Bèr Kessels (01:37.614)
Yeah, certainly. So if you want to test something, a lot of people always try to find out how can I actually test this thing? Because there's a lot of things going on within this X. It might reach out to another service, it might put stuff in the database and so on. So if you want to test that thing, which we call X, you really have to control it. So you'll have to own it and own everything in it.

everything that it reaches out to you have to all own it. Which is pretty obvious if you think about it but it's quite often it's forgotten and people end up in like kind of a testing hell where older testers get really slow or really cumbersome to set up and so on.

Charles Max Wood (02:13.688)
Mm-hmm.

Bèr Kessels (02:28.162)
Yeah, so the idea is that if you can control X, then testing X becomes really easy. That's kind of the reverse of this setting.

Charles Max Wood (02:41.826)
Yeah, I think the way I think about it, and I think you're kind of saying the same thing, is I'm not always trying to control the thing I'm trying to test, but I'm trying to control everything around it, right? Anything that it touches, right? I want to know that it touches it the way that I expect, and that I'm controlling everything that goes into it, which is kind of the same idea. But yeah, so some of the ways that you do this, like in a unit test, it seems pretty straightforward, right?

It's like, you know, I can mock out all the services or anything that it calls out to. I can give it the parameters that I expect. That's pretty straightforward. But as you kind of move up the ladder and you kind of pointed this out in your article, it gets tricky. So let's start at kind of the simplest case, I think, and then move up from there. So yeah, so in the simplest case, is it the unit test or is it something else? Am I off base there?

Bèr Kessels (03:38.17)
No, I think the unit tests is the simplest case. And in Ruby, I tend to even call them class tests because a unit most often is a class.

Bèr Kessels (03:49.53)
But yeah, that's the simplest one. You can test it by just making sure that everything that this class is reaching out to, or like the instance of the class is reaching out to, is controlled by you. So there's nothing external, nothing third party, no third party lips in there. It just reaches out to other classes that you own and that you can control in that test setting. So basically, the thing is often called dependency injection. You'll just.

Set up the class, pass everything in that you control, and then run the test on that class.

And that makes it really easy to test the class or test the unit.

Charles Max Wood (04:25.53)
Did he freeze for you too, Valentino?

Charles Max Wood (04:35.07)
of the internet.

Charles Max Wood (04:40.867)
Oh, you froze. Are you back?

Charles Max Wood (04:53.238)
Yeah, it looks like it was on your end because I could still talk to Valentino. Um, do you want to just pick up where you left off? Just, just start over.

Charles Max Wood (06:05.655)
Right. So.

Yeah, so just to give some ideas here, I think most of the unit tests that I do, it's all internal state, so I don't even have to really do dependency injection or anything like that. But for the people who aren't familiar, because we don't do a ton of it in Ruby in our day-to-day programming, dependency injection, you effectively pass something in that behaves like whatever you're going to touch, and then that's what it talks to. So...

just to give a little bit better case, a lot of times in your constructor, in your class, you'll have a parameter, and a lot of times it's like an optional parameter has a default for what it's gonna use in production. So it'll use the send email class or something, right? Its job is just to manage sending emails. But in your test, what you do is you pass in a double or a mock or a test class for that class, and then it interfaces with that.

because your tests often don't have, you don't wanna actually send emails. And so what you want is you want it to log the request and then give a proper response so that your tests will continue to run as you expect. And so dependency injection is effectively that where you pass in the entity that you're gonna interact with. But yeah, it makes a lot of sense.

Charles Max Wood (07:44.046)
Mm-hmm.

Charles Max Wood (08:10.222)
Mm-hmm. Yeah, that makes sense. I could see that if you're testing like concerns or something like that in Rails, right? Because yeah, then you just include it in a compatible class and make sure that you can call the right things and it does the right things.

Valentino (08:29.369)
So how do you control callbacks?

Charles Max Wood (08:33.838)
Ouch! With great difficulty, no, go ahead.

Valentino (08:42.751)
in models. Right?

Charles Max Wood (09:18.278)
But so that kind of leads to two questions. One is, what do you use instead? And two, what if you have to?

Valentino (09:19.164)
The

Charles Max Wood (10:30.65)
That makes sense.

Charles Max Wood (10:34.179)
Hahaha

Charles Max Wood (10:38.394)
Sorry, I think I might have preempted you there, Valentino. Did you have another question?

Valentino (10:45.807)
I guess I had my biggest thing that I'm always going back and forth on, especially with unit tests is like, how much do you mock? Right? Like how much do you control? And I'm curious what your thoughts are on that because I often find myself just mocking way too much. And then eventually something breaks that maybe if I hadn't mocked as much, it would have

Charles Max Wood (11:05.079)
Mm-hmm.

Valentino (11:13.474)
gaps in test coverage that way, right? If you could start controlling too much and then lose track of it as you start scoping out. I'm wondering what your strategy is for that, for like reasoning about that.

Charles Max Wood (13:03.586)
Yeah, that's interesting. I mean, you know, what Valentino asked, yeah, I've, I've had tests where, you know, I tested the crap out of the mock, right? We're out of the thing I stubbed and yeah. And then I got an error when I ran it in production because. You know, I missed a case or I, uh, kind of contracted a case away or something like that. Maybe it's just, yeah.

But at the same time, it's like, I don't need the full featured service. So yeah, you know, I don't want it to, to try and call out to the world or anything. And so it's, it's a tough balance sometimes.

Valentino (14:12.958)
Yeah, I want to say that my biggest challenge, I guess, with mocking is the external responses, like external callbacks, right? Something like a Twilio callback or GitHub hook, right? How do you mock that and also make sure that it's doing the thing that the external sort

you know, Sora's studs, right?

Charles Max Wood (15:20.09)
Mm-hmm.

Charles Max Wood (16:24.258)
Yeah, and I think that's a lot of what Alistair intended with that, or at least one of the uses was that kind of swappable, the ability to sub something. The other piece that it gives you is then if you move off of Twilio and you move on to some other service that does what Twilio does, you can still test your integration with the same adapter.

Charles Max Wood (17:26.842)
So we've kind of been flirting with the line between integration tests and unit tests, right? Where, you know, your unit test, yeah, so you set up a service that wraps over Twilio or something like that, and then you write an integration test between the two. So, I don't know, I think the line gets a little bit fuzzy though, because a lot of times we kind of conflate the responsibility of the service with the class.

or we see the class as needing to do the job that the service does, right, as part of its job. And so how do you start making sense of what goes in a unit test and what goes in an integration test?

Charles Max Wood (18:32.224)
Okay.

Charles Max Wood (19:43.63)
Yeah, that makes sense.

Charles Max Wood (19:49.046)
When we did in the book club, we did Clean Architecture by Uncle Bob. And you said that unit tests aren't always just a class, but it could be like, yeah, you draw a line around things. And that kind of reminded me of the way that he put together components in your architecture versus say classes or entities or whatever you wanted to call them. And again, that makes a lot of sense. You might have some.

things that look a lot like integration tests just in the sense that this class calls that class or calls that service, but in reality it's still within that bounded area. And so they're kind of made to work together and the integration is really kind of a minor thing. Yeah, the integration test more is, you know, I've got user management and now I've also got, I don't know, if you're working in like a financial domain, you've got your ledger.

management rights. You've got your entries and deposits and all that stuff. It's doing math between them and all that stuff. So yeah, your integration test is, does my user structure or permission structure play nicely with the ledger structure as far as who can edit what or who can change what, who can add entries, who can do that kind of a thing. Then on the other end,

Everything internal to that, where you have entries and maybe an overall ledger or a set of ledgers or a set of accounts that all kind of go in there, those kind of unit test together because they're so closely tied and at the end of the day don't really interact with too many things outside of them except for where you've specifically designed the API to talk back and forth to something else.

Charles Max Wood (21:42.038)
So then you get your integration test there.

Valentino (21:52.65)
Yeah, I wanted to call I really liked your, how you describe the integration test as like, kind of boundary spanking, right? Where you're trying to find and expose the boundaries. And I never thought of it that way. Like integration tests are kind of a good place to discover maybe where boundaries should be drawn that don't exist even. Right? Like if you're having a hard time writing an integration test with the things that work together, maybe

Charles Max Wood (22:02.466)
Mm-hmm.

Valentino (22:21.666)
there's a reason for that, right? And maybe like trying to draw new boundaries could be discovered from those integration tests.

Charles Max Wood (22:38.382)
Well, in the way you describe it, Valentino reminds me a little bit more of TDD, which we all know as a fad diet, if you ask THH. But, you know, that's the idea behind TDD is that you haven't said any of this in stone yet. And of course it's software, so none of it said in stone. But yeah, you can go and explore it and say, yeah, this doesn't fit nicely in the tests as I have them set up. And so I can change the structure in the tests.

and then reflect that into the code.

Valentino (23:14.73)
Yeah, it reminds me of watching Gary Bernhardt's old Destroy All Software. That's where I first came across TrueTDD and it kind of opened my eyes because nothing had been built but the tests. And he explained reasoning about putting together different constructs and objects just through testing which was wild to me.

Charles Max Wood (23:22.138)
Uh-huh.

Charles Max Wood (23:33.251)
Uh-huh.

Valentino (23:45.39)
And it definitely, you know, it reminds me of how you write about it there like with the domain structuring and the tests like It it's very I mean, I definitely do Don't do full TDD But I do more because of how it helps reasoning about things like if I ever If I ever question about what I'm working on or what I'm trying to do like that's where I'll start TDD

Charles Max Wood (24:11.758)
Yeah, it's also interesting you bring up Gary's screencast because he went really deeply into functional core. I can't remember what he called the external piece, but if you look at it, if you squint at it a little bit, it takes a lot of ideas from ports and adapters or hexagonal architecture. And so as you kind of pull these ideas together and start saying, okay, I'm gonna structure this out. These are my adapters, these are the ports, these are, you know.

This is how I designed the API, and then this is how the core is going to work internal to itself. Yeah, you get some really interesting ways of putting the software together that make it really easy to reason about, okay, these are the core features and these are the adapters or services. And so then as you test it and you structure it, yeah, it starts to plug together pretty nicely. Not always, right? Sometimes I just find stuff that just no matter how I do it, I'm just not happy with it.

But a lot of times, yeah, you start finding things that kind of slide into place really nicely.

Charles Max Wood (25:22.755)
So.

No, go ahead.

Charles Max Wood (26:00.698)
Mm-hmm.

Charles Max Wood (26:24.302)
Yeah, I think that's going up just another level, right? Is once your integrations all work nicely right now, it's okay. How does it do front to back and doing those tests? And I'm imagining too that mocking some of that stuff out has got to be, how do I say this? I'll say it sarcastically, extra fun.

Charles Max Wood (27:24.834)
the database.

Charles Max Wood (27:48.006)
That's fair, but in a lot of cases I want that.

Charles Max Wood (27:55.51)
I want that automation to it, right? So I don't want to just open the app and start clicking stuff or tapping stuff, right? I want my CI-CD server to go and do at least some level of, right, even if it's just the happy path and the people can pay me money path, right? You know, just so that at the end of the day, I feel good about, okay, people can get the value out of it.

or at least the core value out of it and I can make money on it. Right. So that I'm comfortable and then yeah, if something else breaks, right. Then I can put a test around that when I run into it.

So how do you do that at the application level? I mean.

Can you mock stuff out there at that level?

Charles Max Wood (28:51.451)
Mmm.

Charles Max Wood (29:58.158)
Yeah, Stripe does.

Valentino (30:17.422)
Yeah, it's funny. I feel like I reach for services that make this easier because then I'm able to test it more easily. But also like just like third parties that have like the tooling built where it just works and then you can stub it out like, and you know, it works well because they built it right. Like I'm always reaching for providers like that. So if you're a provider out there and you're building tools for

you know, that developers can use. I mean, making it easy to test with is like, you know, in for to your advantage, right?

Charles Max Wood (30:56.558)
Yeah, I completely agree. Cause it, and it's not just so that I know that it works, but it's also so that if something goes funny with my account, if something goes funny with, you know, you change the API and you thought, Hey, this is not a breaking change and it turns out it's a breaking change. I find out that my app doesn't work. Right.

Charles Max Wood (31:31.546)
hahahaha

Valentino (31:53.674)
I'm really surprised that there's not a tool that's been made already that just like opens up the page and uses like image recognition to tell where buttons are and just like randomly clicks on things. So like try and get things to behave badly and just see if something happens, you know, like chaos monkey from Netflix for their like, you know, microservices, but just for the UX, right.

Charles Max Wood (32:09.377)
Oh, that would be.

Charles Max Wood (32:18.55)
I know, I would call it four year old or something, right? And it clicks your button like a million times, like click, click.

Valentino (32:25.634)
Right. You know, types all weird characters, right? Like tries control and the sequences.

Charles Max Wood (32:30.482)
Right. Well, it's funny, because you talk about this and before I was a full-time developer, I did QA and of course I told them, hey, I'm going to automate this stuff. And they said, no, you're not. And so like I had to go and I had to, I mean, this is what I did, you know? And yeah, it was never, because you know, most of the Happy Path stuff,

You know, the developers that were working on it and I do this too, right? I'll run through it and it's all happy and it does what, you know, what I expect it to, but yeah, it's when I put funny characters in or, you know, uh, click the UI a zillion times or, um, you know, try and give it an, an input or output or try SQL injection or, um, you know, just all kinds of weird stuff. You know, that, that was my job.

Valentino (33:29.43)
You know, another, it's another reason to have integration tests or just like system tests. I don't know what you want to call it these days, but like something that goes to a browser and clicks around. I mean, once you get like a huge app, right? Like I find myself just running them locally and like watching the browser do its magic so that I know how to use the app. Right? So like I use it as product exploration, right? Where I'm going and I'm, I'm watching the test run.

Charles Max Wood (33:55.575)
Oh, interesting.

Valentino (33:57.698)
so that I know, like I'll find something new all the time. Like, oh, we have this whole new product or only thing. And I'm like, I didn't even know we had that. And like, there's the test, like getting it to work and then I'll go in and try on my own later. And it's kind of like a fun use case for that. Like trying to just explore what you have built or somebody else on your team.

Charles Max Wood (34:22.602)
you running like your Cypress test or something.

Valentino (34:26.774)
Yeah, I like Cyprus or Selenium or something, right? Just watching Chrome turn away.

Charles Max Wood (34:37.157)
So one other question that I have with some of this, right? Cause we're talking about Ruby in particular, but.

How do I put it? So I see people a lot of times they'll have a Rails backend and then they'll have like a React or a Vue frontend. So do you change your approach on some of this stuff with that?

I guess you wouldn't have to until you're getting to like the app testing, right? Make sure the React app plays nicely with the Rails app.

Charles Max Wood (35:27.053)
Ah.

Charles Max Wood (35:52.474)
know that makes sense and it's not my fault if they're doing it wrong right

Charles Max Wood (36:01.142)
No, but it does make sense in the sense that, yeah, you're making sure that you're fulfilling your end of the contract with the other apps.

Charles Max Wood (36:21.562)
Mm-hmm.

Charles Max Wood (36:56.23)
So are there any other aspects to this that we haven't talked through?

Charles Max Wood (37:05.427)
I did think of one thing that I wanted to throw at you, because I think most of the time when I've done mocks, I've used some kind of test double library, right? Even if it's just kind of the test doubles that come with our spec or test unit, or it's not test unit anymore, it's mini test. Gosh, I'm old. Anyway, so you said that you do this by just creating a class.

Charles Max Wood (37:32.17)
I mean, I'm curious how you set that up. Do you put those in your test directory as just the, you know, something, something double or how does that work?

Charles Max Wood (37:50.681)
Uh-huh.

Charles Max Wood (38:58.054)
Cool.

Charles Max Wood (39:05.306)
Valentino, you have anything you want to add or ask?

Valentino (39:09.107)
Yeah, I was curious if you use like any, I wanted to dive into the testing tooling that you use because you've got a pretty good grasp on like very definitive things to test and maybe the overarching architecture of testing. So there's got to be some great tools in your toolbox, right? Like what are your go-to's like top three for when you're like, that you use across all of your apps, you know, for testing?

Valentino (41:04.49)
Yeah, that's so useful. I have something similar in Vim So I guess I was trying to lead you to you know factories or fixtures, you know What this is probably it's probably the crux of testing for me like that drives me insane is you know as the testing files grows like These things break right like

There's so many interdependencies on the models and relationships. And how do you best keep track of that? Like I've been using FactoryBot for the longest time. And, you know, I still like using just regular, you know, the fixtures from, from Reels. But I still like anytime that there's more than, you know, two or three interdependencies is just like a nightmare.

And I'm always like, I'm always like trying to reshape it or redo things so that it works better and that I'm not just like randomly creating a ton of records every time that I want to just test something right in isolation. Like what's what is your solution to that?

Valentino (43:37.478)
Yeah, that makes sense. I guess like, how do you prevent the chain reaction of, okay, a user has many of everything in your app, and the factory defines that it has all these things and just initiating the one user factory now generates a slew of other factories.

Charles Max Wood (43:50.435)
right

Valentino (44:03.886)
And it does, it slows things down when you're running tests, you know, very easily. And I know there's like, you know, you can have like, you can describe in FactoryBot how you build certain dependencies of the factory, right? So that it only initiates the active record object, but not that it doesn't save it to the database or something like that. But still I feel like,

there's still no good solution to be like, all right, I want this factory, but you know, not the extraneous stuff. Like, you know, and I find myself just creating a bunch of traits for factories so that I can have slimmed down versions of isolated things. And then it just becomes a mess, like trying to manage all of that. And I wish there was like a way to like, just make it automatic, you know, where like it knows how to handle this particular kind of thing, you know.

And maybe it is just how I'm modeling it, but.

Charles Max Wood (45:36.182)
Yeah, I think the way that I've seen it with factory bot where, yeah, you don't want all of the zillion different dependencies. You don't need 10 of all of them. Um, is that, yeah, you create factories that just generate the ones you need for the different test cases, but then you have to keep straight which factory you're hitting in order to get what you want. And then you also have to keep straight that you're not running other factories that.

Valentino (45:36.482)
You did it.

Charles Max Wood (46:04.894)
may change what you get.

Valentino (46:12.662)
Yeah, I mean, it reminds me there's like that concerning block you can give to models, right? Where you can define a belongs to and has monies and all those associations like in blocks. So you can say, okay, like in the context of this thing, I was hopeful when I saw that, that there was just like some automatic test mechanism that would just like, okay, I want this, this concerning group, right. And in my factories. And I don't see that anywhere. Maybe I just need to build it.

But I was so hopeful that was like the solution to be like, okay, I really only want this giant model that has these particular concerning items for this, right? And someday, I know I'll get there, but it's like, rails have been around so long. You think this is a very common thing to go wrong.

But we'll see.

Charles Max Wood (47:09.638)
Good deal. Well, if there's nothing else to jump on, I think we're gonna, I'll push us into picks. But this was a lot of fun. Yeah, Valentino, you have some picks for us?

Valentino (47:26.382)
Uh, yeah, I've been following on this crazy Twitter explosion over this paper that came out on, uh, it's a technical paper on room temperature superconductors. Somebody has supposedly made one, uh, in a lab and it hasn't been peer review or hasn't been peer reviewed, like reproduce in labs yet. And so now there's like all these labs on Twitter, like openly like going through that process and it's kind of.

really exciting. Cause you know, if a superconductor can be, can happen at room temperature, there's like all kinds of crazy innovation that's about to boom related to that. And so it's like kind of wild to see just like the explosion of responses happening. So I've been following that.

Charles Max Wood (48:14.566)
That is interesting.

Charles Max Wood (48:19.142)
All right, I'll throw in a couple of picks. I always start with a board game. This is a board game I played with my friends last week. It's called Living Forest. And Board Game Geek has a weight of 2.21, so easy casual game. Says 40 minutes, I think we took a little bit longer, but it was my first time playing. And anyway, so effectively what you're trying to do is you're trying to be the first person to get to

12 of a certain kind of token. So you have like lotus flowers, which show up on your cards and your board. Um, and everyone has their own little board. And then what you, what you do wind up doing is you can buy trees that go in your, in your forest, that give you bonuses. And then if you fill certain rows or columns, you also get bonuses. Um, you get animals and the animals also give you certain, um,

basically tokens, things you can spend, which is water, sun, I can't remember. Lotus flowers is one of them, and lotus flower is one of the tokens you're trying to get to 12 of. You can also have 12 unique trees, you can get 12 fire tokens. And yeah, there's a fire spirit out there. So if you don't have enough water to overcome the fire that's out there at the end of the round, then you have to take a fire gremlin. I can't remember what they're called, but basically,

It's just a blank card in your deck and you play your deck out until you have three of the wrong kind of animals basically. Some of them give you bonuses, but once you have three of them you've busted and so you only get one action instead of two. I don't need to explain the whole game. But anyway, it's kind of a nature-themed game. As soon as somebody gets to 12 tokens, 12 fire, 12 trees, whatever.

Then everybody else gets a chance to finish the round. And then what you do is anybody who got to 12 tokens, um, they can add up all of the things that would count toward a 12 token set. So all of your Lotus flowers, all of your trees, all of your, um, fire tokens, et cetera, and then whoever has the highest total wins. So if you're the only one that gets to 12, you win. Um, but if not, then the tiebreaker is all the other.

Charles Max Wood (50:47.654)
kinds of tokens. And it was fun. It was a lot of fun. There are enough moving parts to where you really kind of have to figure out what you're going to prioritize. But once you've played the game once or twice, you also figure out that you can't ignore the fire tokens. Because initially when we were playing, I had a ton of water. And so I left the fire tokens out there so that the other two guys would have to put dead cards in their deck. But what I figured out was...

Uh, one of my friends wound up buying like four fire tokens. And so that got him well on his way to getting 12. And that was the fastest he was going to get to 12 fire tokens faster than I could get to 12 of anything that I was doing. And so, um, me and the other guy had to wind up buying fire tokens or, you know, getting the fire tokens with our water because we didn't want him to win. So, um, that's, that's the other piece of the game is you do have to balance the, the fire, but everything else. Yeah. It's just a matter of just.

building your sets, building your deck, figuring out which actions to take. It was a lot of fun. So I'm gonna pick Living Forest. And then a couple of other things. So last week, my wife and I, I'm gonna be a little bit long-winded because I have a whole bunch of things that I'm picking. Last week, my wife and I decided to do a double feature at the movie theater. So we went and saw two movies. One of them is Sound of Freedom.

And it's about Tim Ballard who founded Operation Underground Railroad, uh, goes out and finds children that are being sex trafficked and rescues them and works with local governments to get these people arrested and really, really enjoyed it. So, um, I'm gonna, I'm gonna pick that. Um, some parts of it, like they don't, they don't get into any graphic stuff.

But some parts of it are hard to watch because you can kind of see it coming and then they cut to the next scene. Um, and then, and you just see the terrified look on these kids' faces, right? I mean, they're actors. They, you know, they didn't put them through anything filming the movie, but still. Anyway, and two, the two kids that are the main kids that they're looking for are the same ages as two of my kids. Uh, the, if, if you reverse the genders, cause I have a son and a daughter that are that age, but

Charles Max Wood (53:06.842)
through the other age of the other kid. The other movie we went and saw was Indiana Jones and the Dial of Destiny. And they hit a lot of the nostalgic chords that I wanted them to hit with Crystal Skull, so I enjoyed that. The plot was okay. But yeah, it was worth seeing. So I'll put that out there as a pick.

And then the last thing is, is I'm getting ready to launch. I was initially going to do like a podcast bootcamp, but I may eventually do that. But what I'm doing instead is I'm going to launch a podcasting for programmers group. And it's just going to be kind of a mastermind group coaching group. So for, if you're interested in learning how to do a podcast, you want to do about programming topics, um, you want my help kind of figuring out how to get it started. Uh, we're going to do weekly calls with the group.

Just whoever signs up, probably going to have topics for most of them and then a Q&A once a month. That way we can kind of work through, okay, here's how you get your artwork or here's how you attract the right kind of guests or the right kind of audience or things like that. A lot of the advice I have about podcasting is just, it'll work for any podcast, but there are some things that you run into as you're podcasting about programming that other podcasters just don't really think about. For example...

We're talking about code, but it's kind of hard to talk about specific instances of code because reading the code on the podcast sucks. Right? And so there are techniques and ways to get around that. There are ways to open that up. So if you're interested in that, go to topendev.com. It'll redirect you to the group. You can sign up. The initial sign up is going to be $49 a month, which I think is a terrific deal for four calls, five calls a month.

And I'm probably going to raise the price after I have 10, 15 people in there. So, just as a heads up, that's the direction we're heading in there. And I'd love to get, you know, people in there and have a good group of people where we have a good discussion every month. And then from there, what I'm hoping to do is just get clarification on where people struggle with podcasting, because I've been doing this for so long that a lot of this stuff just seems obvious to me.

Charles Max Wood (55:28.634)
And then I'll put together the bootcamp course and put that up for something you can sign up for. So anyway, those are my picks. Bear, what are your picks?

Charles Max Wood (56:56.006)
Cool. All right, one last thing. If people wanna connect with you, where do they find you? Online.

Charles Max Wood (57:25.758)
Awesome. I'm also just gonna throw in, I was in Amsterdam at the beginning of June, and the cool country you live in. All right, let's go ahead and.

Valentino (57:36.643)
Are you going to Railsworld?

Charles Max Wood (57:39.657)
I wish.

Charles Max Wood (57:55.63)
Yeah, well, it sold out in like two seconds, so.

Charles Max Wood (58:01.742)
All right, well, we'll go ahead and wrap up here. Till next time, folks, Max out.