When working with software or applications, developers and programmers encounter a variety of distinct system issues or problems. The Rogues join the show to share their thoughts about troubleshooting. They discuss identifying and fixing system problems in their applications, whether they're at the front end or the back end, using their own experiences as examples. Additionally, they talk about some of the tools they use to help them fix system issues or errors.

Hey everybody and welcome back to another episode of the Ruby Rogues Podcast. This week on our panel we have Valentino Stoll.

 

Hey now.

 

John Epperson?

 

Hey everybody.

 

Dave Kimura.

 

Hello everyone.

 

I'm Charles Max Wood from Top Endevs. And this week, Dave recommended a topic for us. We're going to talk about troubleshooting. Now, I'm wondering, Dave, is there like some story behind this? You know, some pain you saw someone going through? Or I don't know.

 

I don't know if it's pain that I've seen someone going through, just more of a pattern. And I think it initially starts with, do we understand the questions that we are asking? Do we understand or know how to ask good questions, providing relevant information, not too much information? And then how to identify or diagnose issues on the front end. the back end and our environment in general. So it's just something where I'm a part of several different development communities. I also get comments on Drift Ruby and a lot of times the questions that are coming in, people asking for help, like they legitimately have a problem. They are just not either articulating it in a way that anyone can help them or they are not doing their own research or due diligence because either they just don't know how or some other reason. And so I just thought it would be a good topic to say, you know, hey, as developers, we all run into these kind of problems. Some of us know immediately how to resolve them. But then other times, especially if you are newer to the game, you may have a lot of trouble trying to figure out like, how would you go about solving these kind of issues? So, I thought it'd be a good topic.

 

Sounds good to me. I'll tell ya, so I've been working on this contract and we're writing scripts that essentially integrate two systems through their APIs. So we're writing glue code, sits in the middle. And sometimes that gets tricky. Because is it my code, is it their code? Is it, right? So, you know, maybe you'll give some tips that I can pick up because sometimes it gets really hairy.

 

Yeah. And depending on the kind of information that you're passing through, it could also be very sensitive. Like if you're passing over a lot of personal identifiable information, you know, sometimes the easiest thing to do, especially if your application is not big, is to take a snapshot, throw it in your local environment and then replicate the issue. But that's not always the best route from a security standpoint.

 

Right.

 

So, but you know, just if we just kind of started the very basic, we have our development machines. Now, do we really understand how our development environment is set up? Or is that a impediment often as you were doing your development work? Now, I'm not saying that you have to go out and buy the latest and greatest fastest machine, but do you understand your operating system? Is this issue local or if I deploy are we going to see the exact same kind of issue?

 

Yep.

 

I think a lot of this also gets into the difference between troubleshooting your app, right, and troubleshooting your environment, which for me are very separate issues, right, because my experience with people has been that, you know, it's not really a big deal. Like, if you create an environment, some people who are not very good at troubleshooting their machines are still gonna be productive at, you know, Dealing with an app, but if you're like a single-man shop or something like this, right? Like you're stuck with having to do both things so, you know that you can get away with not being able to troubleshoot your machine if you're on a team where you don't have to but If you're on a really small team or or that one-man shop, you're gonna have to be able to do both things

 

Yeah, and I think things have really gotten a lot better over the past couple of years. It used to be a lot more of a concern, but if you switched over to a Apple Silicon machine, and if you were still having to support legacy applications that are running Ruby 2.3 to 4 to 5, whatever, then you could have issues if you try to boot those up right off the bat, you know, on your new machine,

 

Mm-hmm.

 

arm version of Ruby is just not going to work. I had to deal with that when I switch over to Apple Silicon and I had a couple of legacy applications that the business had no intention of maintaining. They were just going to let it naturally through natural attrition sunset itself. So the first thing I did was dockerize these applications the first time I needed to work on them and that allowed me to get a. local environment. And if you've ever had to work on a Rails 4 or previous application and deal with the libv8 or the Ruby racer, it's a real pain, especially if you

 

Yeah.

 

have updated your application and time has passed, or if you've updated your environment and time has passed, you're now running a newer version of libv8, you're not going to be able to bundle the gems, and it's just, it's a nightmare. I think being able to get outside of these kind of issues can make us more productive developers. And my pretty much go to answer for that is dockerize your application. Use Docker on your local development environment to do your development. That way you don't have to worry about a lot of these system dependencies that you otherwise may really kind of struggle to get through them.

 

100% and I think especially if you're maintaining multiple apps at the same time.

 

Yeah.

 

Because I mean I think your use case is really, really like one of the best use cases for Docker, right? Hey, I'm maintaining multiple apps, some of them are really old and some of them are not, right? When you have that big mixture, you know, it's a big deal. But even if you don't have the mixture, it still helps to be able to separate everything a lot.

 

Yeah. And I know that Docker does have

 

Mm-hmm.

 

learning overhead. You have to understand what is a container, what is the image, how does my data persist, how do I port forward? And those are all legitimate concerns, but I think as developers, we would be much better in the long run if we took the time to learn those things. Learn about the Dockerfile and Dockercompose.

 

I'm on the fence with this.

 

Hahaha

 

I

 

Fair

 

don't

 

enough.

 

get me wrong. I love Docker and as you get more experience, it's definitely more helpful, especially managing many, many things. But like I'm just thinking back to when I first learned Rails, which ultimately is how I learned Ruby. And you know, it was hard just to understand like model view controller. And I mean that not that Rails is like Even the implementation of Model View Controller isn't that great. You know, it's so hard to get started with the framework from ground zero. And like, I remember having to, you know, debug the most minor things, you know, let's say like, oh, I missed an end in my controller, which I know there's like gems now to help me find my ends, but like, just some most simple nuances of things were hard to troubleshoot from the regular log with just like the system Ruby and Rails running that adding a whole extra layer on top of that that I don't understand to begin with. I feel like maybe first for beginners and like getting people into the community and using Rails, maybe Docker isn't that great.

 

Yeah. Yeah. And if you're just getting started, Docker may not be the answer because you don't have legacy applications to work on.

 

Yep.

 

Now, if you're just getting started learning for yourself. But I think having an understanding when there is a brute command from a tutorial that it's telling you to run, that you actually understand what it's doing, you know, those kind of things, taking the time to learn, you know, instead of just copy pasting from the Internet, I think is going to serve you better than the long.

 

Yeah, okay, so I mean, I 100% agree, right? My sense though has been that there's two kind of groups of people that are sort of joining the community, right? There's the, hey, I'm starting, just trying to figure this out, I'm doing my app all by myself, right? And yeah, I 100% agree. That person, you probably don't wanna say, you also need to do Docker and you also need to do these 10 other things, right? That's a lot to lay on that person. But the other cohort of

 

you

 

people that are joining the community are people that are joining teams. And for those people, like, I think, like, the right suggestion is to say, do what your team is doing, right? Like, and that's, like, basically what I always tell somebody that's, like, just starting, is it's like, okay, what's your support system going to be like? You're joining a team, so

 

you

 

do what they're doing, right? follow

 

Mm-hmm.

 

their things. Even if everything you heard me say in the past 10 minutes is in complete disagreement

 

you

 

with them, just do what they have to say, right?

 

I'm sorry, I'm sorry.

 

Because they're gonna be your support system every day.

 

I'm sorry, I'm sorry.

 

And if they're

 

I'm sorry, I'm sorry.

 

doing Docker, do Docker.

 

I'm sorry, I'm sorry.

 

You know, like they're gonna theoretically

 

I'm sorry, I'm sorry.

 

support you in that, things like that.

 

I'm sorry, I'm sorry.

 

And if they're not,

 

I'm sorry, I'm sorry.

 

you know, maybe when you're

 

I'm sorry, I'm sorry.

 

in and you're feeling a little more confident in

 

I'm sorry, I'm sorry.

 

things,

 

I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry.

 

like and you want to do it on

 

I'm sorry, I'm sorry.

 

Day one, yeah, I agree,

 

I'm sorry, I'm sorry.

 

it's gonna trip you up.

 

I'm sorry, I'm sorry.

 

Yeah, I completely

 

I'm sorry, I'm sorry.

 

agree with that, John, even if they are

 

I'm sorry, I'm sorry.

 

going against best practices

 

I'm sorry, I'm sorry.

 

and crazy,

 

I'm sorry, I'm sorry.

 

crazy development setups.

 

I'm sorry, I'm sorry.

 

If you stick with how they

 

I'm sorry, I'm sorry.

 

are doing it for

 

I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry.

 

your work related things, then when something goes wrong, that lead or senior on the team is actually able to help you instead of spending the first hour trying to understand what your environment actually is. So that's a good point.

 

I think all of these discussions that we have make the presumption that you're confident enough in your abilities that you're willing to experiment on your own. Because otherwise, yeah, you just do what your team does is the correct answer 100% of the time.

 

So back

 

Yeah,

 

on

 

I

 

the

 

agree

 

topic

 

too.

 

of troubleshooting, I'm sorry to derail

 

Hmm

 

us with the Docker argument. But what do you guys do when you're like first, I mean, I know that like the spectrum for where you start your troubleshooting is like kind of huge. Like

 

Yeah.

 

where do you go first? Like what's your first thing when you're like troubleshooting just something in the real estate?

 

So can I deviate from your question specifically

 

Ha ha

 

about

 

ha!

 

the Rails stack? Because... I have a very intimate computer background. You know, I did sysadmin work for many years. I've done programming for double that amount of time. I've had computers growing up, super big computer nerd. But every now and then, I run into an issue that just completely floors me. And I had this a few weeks ago. And it was nothing to do with programming, but it was a environment issue. So I was doing a recording on this week on rails. It's a video coverage of a newsletter that I do. And

 

Mm-hmm.

 

the issue that I had was I was getting some blips in the audio. So there was some artifacts coming in every few seconds and I could not figure it out. I had upgraded to Mac OS Ventura and I was using screen flow to record

 

I'm sorry, I'm sorry.

 

these. But I thought

 

I'm sorry, I'm sorry.

 

it was just some hardware

 

I'm sorry, I'm sorry.

 

issues or something else.

 

I'm sorry, I'm sorry.

 

bad. So

 

I'm sorry, I'm sorry.

 

what it ended up being

 

I'm sorry, I'm sorry.

 

was there was an issue

 

I'm sorry, I'm sorry.

 

with ScreenFlow

 

I'm sorry, I'm sorry.

 

and Mac OS

 

I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry.

 

Ventura recording at 48 kilohertz. If you record at 44.1 kilohertz then the issue is completely fine. So

 

Oh

 

trying

 

wow.

 

to coming to that conclusion was extremely difficult. I ended up for a while because I didn't have time to really get into the intricate details revert back to Mac OS Monterey. So I rolled back my operating system for a bit. And then I thought, you know what Mac OS Ventura is out now, it's stable. There's going to be more use cases. I'm going to upgrade to see if maybe something has fixed itself. No, it was still doing it. I was at a crossroads. Do I want to get a second computer running Monterey just so I can continue troubleshooting this but not lose productivity? Do I want to roll back to Monterey and not be on the latest and greatest OS? Or do I want to see if I'm able to replicate this? So that's when I really started doing some more investigative work. I then pulled up another screen recorder application recording with the same kind of settings. And there was no issue. So that tells me that it's not related to my operating system and it's not related to the Amount of data that I'm trying to record like a 4k video feed or anything like that It had something to do with the application I was recording with so I then go to the forums of screen flow a screen flow telestream forums and stuff and I found out there was someone else who had that issue and there had been some back-and-forth with the developers and And it turns out that's where I discovered about

 

you

 

that 48 kHz issue. So it's something that I never even thought of, but I was able to do my research once I had a more, a better idea of what I needed to be searching about. So even though I really have very little idea about audio and stuff, I knew something wasn't right and I was able to go through a process of elimination of what the issue could or could not be. and able to then do the research online to then find my answer. So now until screen flow fixes it, I'm recording at forty four point one kilohertz.

 

Yep.

 

That's really funny.

 

Yeah.

 

I've had fun excursions like that.

 

I mean how much of this is trial and error then? How do we get away from trial and error?

 

I mean both, well, what Dave described is what is not exactly trial and error, right? Like so he described like, you know, basically trying to say, okay, let me create a test, right? So I can determine it's not these things, right? Then you try to eliminate some things and then you're like, okay, well, you know, it's related to this thing. So let's try Google searching and then, you know, after you Google search, you know, if you don't find anything, you know, maybe you go on to other steps. They found something in the Google search, but like, yeah, I mean, I don't know. I start off with trial and error. So to like start us off there, like, because, you know, at this point, so let's go back to the Rails because you asked about Rails, right? So when I run into a problem with Rails, the first thing that I do, right? Because I've done Rails for a long time now is I'm like, it's probably not all these things, right? It's probably this. And so like I'll trial and error in that area until, Let's say, you know, 15 minutes, 20 minutes have passed and I'm like, all right, something's wrong. I can't figure this out Then then I probably go to Google search, right? Then if I can't find something there, then I probably start like Stepping back and creating tests for it. So I generally don't You know dive into like that testing thing. That's usually my like third or so step an hour later. I will say

 

Yeah,

 

that

 

I

 

does

 

have

 

get

 

to say.

 

me into trouble sometimes, but...

 

Yeah.

 

Go ahead, go ahead.

 

Well, I was just going to say, I mean, trial and error, a lot of times you just double check the obvious stuff and that's the trial and error I go through. And then I go through some of the other things you mentioned.

 

And because we are using someone else's code, essentially, that is what Rails is. It's a massive number of people who have created something that we are then using. If I run into an issue that I cannot explain, I'll create my own dummy application to try to recreate

 

Mm-hmm.

 

it with the minimum number of interferences. So meaning that it's a fresh Rail 7 application. else to it. And then I set up the example that will not only allow me to get community feedback if I am able to replicate it there. So someone else can then because I can share that repo, maybe it's not proprietary information. I can share it with someone else. They can have a look at it, help me out. Or if it is, in fact, a bug with a gym or something like that, then I can share the repo and create an issue on that particular project. And then the community as a whole would be better for it once it gets fixed.

 

Do you do that before or after looking at issues on the repo and going to, um, I almost said Reddit, but I meant Stack Overflow.

 

I actually never go to stack overflow as a direct path

 

Right.

 

if a Google result takes me there then I'll go there but it's not my first

 

That's my pattern too,

 

place.

 

actually, but yeah.

 

So I mean,

 

I

 

I

 

mean.

 

try to do as much, you know, the obvious stuff like you guys said first, and then I will if I just cannot explain it. And that comes with experience to know, you know, okay, something really funky is going on here. Usually, it's been around some kind of asset that I've made a change to a file, but then my assets aren't getting updated, something really strange is going on. days.

 

So caching problems.

 

Yeah

 

I mean, how should I put this? Cause I wanted to go back to the Stack Overflow thing, but I also wanted to hit, there's the two hard problems in computer science, right? Naming and caching. And anytime that we're dealing with assets, right? We're talking about a lot of different caching things going on. And I feel like that has always been one of the places where I end up having those problems that I can't explain. around assets because of caching things.

 

Right. Well, and it's a behavior that you don't always control or you can't, oh, you know, because it, it has all kinds of rules for how it manages the caching. And so

 

Yeah,

 

you

 

or

 

may

 

there's

 

not get

 

multiple

 

a consistent

 

layers

 

result.

 

of caching.

 

Yeah.

 

And then and then if you want to like test something, you're like, OK, I need to remember all of the different places that caching could happen and I need to go

 

Mm-hmm.

 

remember how to reset all of them. So testing those can can be harder. So it's not I mean, and this actually gets into like one of the things like I tend to put testing last in my system, right? So in my troubleshooting system, so Even if I think that I know, for example, all the places that I need to go to cache, I'm probably gonna do some Google searching first to see if somebody ran into a similar problem

 

Right.

 

before I begin to design my test because I consider that to be a high effort thing with risky rewards, right? I may or may not hit the thing, hit the problem. system and low effort things go first, right? So for me, Google searching and racking my brain for previous, you know, things that I can remember are like those are the first steps for me.

 

Yeah, one other tool that I find is low effort is doing a get diff back one or two commits because typically what will happen is something will change and that's why it's not working. And so I can go and I can eliminate anything that didn't change since the last time I knew it worked. And so I can go, anyway, I use that to kind of narrow things down. Usually if you've been working in the code, you know about where it is anyway. Sometimes I'm just completely lost.

 

Yeah, and you can also do a git checkout of that specific

 

Uh huh.

 

commit. So if you do a

 

Yep.

 

git log, you'll get that commit hash for each

 

Yep.

 

commit. And you can go back if you do a git checkout on that specific commit and then run the application to see if you can reproduce it. If you were not able to reproduce it, then

 

Or if

 

it

 

the

 

was

 

problem

 

something

 

goes

 

that,

 

away, yeah.

 

yeah, something that was recently introduced.

 

It also depends on the nature of your codebase too.

 

Yeah.

 

So for example, I worked in a codebase where there's a lot of committers and there were long running branches and there was a lot of rebasing that went on. And I'm not saying that any of these things are evil in and of themselves, but in that kind of environment, it was actually, I would be like, yesterday doesn't mean that it was a recent commit. It could have been something from

 

Mm-hmm.

 

a while ago. Someone rebased and did some merging and the whole entire history just got changed on me. So it can be hard to find it in that kind of environment.

 

That's

 

So

 

true.

 

depending on your environment, some of these techniques may or may not apply is all I'm getting at.

 

Yep. One other one that I'm curious where you all put it, right? Because it sounds like we all reach for the intuitive thing that, you know, is the least amount of effort. Um, where do you put the debugger? So like a by bug or a... or tools like that.

 

I'm very fast to jump into Pry, but it kind of depends on what the problem is. So, for example, if I'm dealing with assets, Pry is not very helpful.

 

Right.

 

But if I'm having a logic problem, I'm actually

 

Yep.

 

probably going to hit up Pry really fast. Also, if it's something that I intuitively think is a logical issue, be going to Google for that because Google isn't

 

Yeah.

 

going to help me fix my logical issues. Google's just going to help me fix things that, you know, somebody else's code is causing a problem with my code, right? So the Rails framework, I'm using it wrong or, you know, something like that.

 

Mm-hmm.

 

Yeah.

 

No, admittedly, I don't use pry or by bug. I'm a big fan of emoji debugging. So just puts debugging and I'll put some fire emojis or something in there. Just so when I tell the logs, I see it pop out there really quickly and easily. But.

 

Oh, I haven't thought about that. I always just type something in like explode here or something.

 

Yeah, emojis,

 

And then, and then it

 

man.

 

comes back

 

Gotta

 

and it says,

 

use them.

 

I don't know how, I don't know how to explode.

 

I mean, for me, I feel like both are kind of like highly overlapping, right? Because, you know, I mean, what I do when I hop into Pry most of the time is I'm kind of inspecting variables. So

 

Mm-hmm.

 

I'll use puts to, you know, print out like some stuff before I get to, you know, someplace, right? And then I'll be like, okay, based off of all those puts, right? It's kind of like using the watcher in an actual debugger, right? history as you go through all the steps and things. So for me, the puts becomes all the history. And then I get to whatever location that I'm, you know, having some sort of problem in it. And now I'm in pry and I'm like, hey, what's my variable value here? And then because I'm in pry, if my variable value isn't what I expect it to be, I can now muck around and look at stuff too.

 

Right. Speaking of debuggers, I haven't used it extensively, but RubyMine actually has a debugger that's built in, right? So you tell it to run your app and then you can set breakpoints and you can run it. I haven't set anything like that up in VS Code. To be perfectly honest, I don't even know. I'm sure there are extensions that will do it. Do you all use any of those kinds of debuggers?

 

I think if I was starting out, I would probably invest some time in my tooling to investigate that. And I have played around with the debugger within VS code and it does, it can work for Rails apps, but I just, I'm not at a point where I don't do that. I'll just rely on the puts debugging.

 

I'm a huge fan of Ruby Jard. It is so

 

jarred.

 

cool. It is very hard to go back any other way.

 

What is Ruby Jard? I don't know if I know that one.

 

They call it just another Ruby debugger,

 

Oh.

 

but it gives you all like contextual stuff based on the current stack frame you're in in Ruby. And so you can see what all the different instance variables are or things like that, that are in line to wherever you say, hey debugger stop. It's very similar to Pry in a way, except it gives you a

 

Hmm.

 

lot more context so far deep into the current context, it's just incredible. I do find myself getting away from it for the new IRB stuff and doing binding IRB a lot more, but

 

Mm-hmm.

 

there's just so much that gets missing. Once you get your groove with something, it's hard to go back.

 

Right.

 

So I just looked it up. It looks like Jard is... It's like it's Pry and ByBug underneath. But it also looks like it... So Pry has... There's like a Pry debug or something like this. And it looks like Jard is not using that, but it has its own debugger to go around with. And it looks pretty, and it displays some nice looking stuff.

 

Mm-hmm.

 

It looks cool.

 

Yeah, one of the

 

I can

 

things

 

see

 

I

 

why

 

like

 

you would

 

about

 

like

 

it,

 

it.

 

yeah, I really like it has like a personalization like customization stuff so you can even get it so that it has customizations per application. So I mean, I've gotten to the point where I even have it set up for certain applications to have special things in it. So it's so easy to use.

 

I'll have to check it out and see how

 

Nice.

 

it compares because I'm not like a Bybug power user or anything so I don't think

 

Um.

 

I'll lose anything by switching.

 

So

 

You know.

 

on the debugger versus like Pry before we completely leave, like I think that the Pry jarred, like the whole REPL debugging, right? So I've had this discussion with somebody before, and I think that REPL debugging basically effectively replaces debuggers, right? Because the things that you want from a debugger can generally be replicated in a REPL debugger, of the time. And then a REPL debugger also gives you things that a debugger does not. And so I think effectively, even though they are different, I think that REPL debugging kind of just obsoletes debuggers when they're available, right? Because not all languages can do that.

 

I mean, effectively, you're putting in a breakpoint that calls a method that gives you access to the context that it's running in.

 

Right.

 

And either way, whether you have a visual debugger or command line debugger, you're limited to, you know, the quality of the tooling and the information that it knows how to get to. So I agree with you to that extent. right out of the box is the only comparison that I would make that makes it different, right? So I'm thinking more like the web tools, right? So if you put a debugger in your JavaScript, instead of having to query it for the context, it will show you the context, right? Because it just loads

 

Yep.

 

it all into the UI. But...

 

To be clear, I would note that I would consider the JavaScript tooling to also be a rebel debugger most of the time, right? Because you almost always have access to the console right there.

 

Yes, it's kind of both,

 

Sure,

 

but yeah.

 

and I mean, I think that we're looking at like, yeah, some overlap as well, right

 

Yeah,

 

here.

 

but for the most part I agree with you, right? You're telling it where to stop and then you're looking for the information you need.

 

Yeah to move on from debuggers for a moment to Undefined method for nail class

 

Ha

 

I think

 

ha ha ha!

 

as rails developers that is going to be one of the most common Errors that we come across And

 

Still.

 

I think Yeah And I think that as a beginner that could really throw you off of what does that even mean?

 

Yeah.

 

if if you have something like a Rails application dot credentials and then you were trying to Chain in You know, maybe like AWS and then secret key It's very easy to get that undefined method square brackets for nil class if you do not have that top-level AWS defined so It's very overwhelming at first to you get that error message along with the rest of the stack trace. If you have ever gotten a Java error, that's kind of what it kind of leads me or my brain initially goes back to where you get this huge wall of text. That means absolutely nothing to me. So understanding how the error messages work in Ruby, I think is really important for our debugging. that you know show up in your logs and If it starts from one and then goes two three four Then that means the most important information or where it actually aired out is up at the top But in newer Ruby versions, they actually reversed it So the errors at the bottom and the backtrace kind of goes the reverse order But usually

 

me at

 

Yeah

 

first.

 

usually there is file path with a colon and then a number that will tell you this is the file that we are having an issue with and then this is the line number in that file that threw the error. So now you have somewhere that you can trace back and if you are in a situation where, okay, this takes me to a class within that class of method and in this method it's doing something user.active and you're getting undefined method active for nil class. Well, why are we getting that error message? So you need a trace to back up to something else. You can take it to the initial initializer of that class. But if you go back into your stack trace or in that error message, then in the lines above or in the second or third lines, wherever or in the file path of your application, you're gonna see what called that method or what led to that method. So you can then start backtracing from there to say, okay, let me go to this other file to see why it called this method in this other class that eventually threw the error. And then you may see that you're passing nil for the current user or something else. Now you can do some debugging there I'm expecting to be defined actually not defined.

 

Well, and that's where some of the other techniques come in, right? Because you start putting those logging statements or put S statements or. You know, whatever, so you can get a feel for what's there. Right. And, and yeah, the, the call traces, what's telling you where to put it.

 

The backtrace in Ruby is tough. And I think

 

Yeah.

 

one of the biggest things that got me at first was the lack of separation between your code and external code, like libraries. And even to the point of like internal libraries, right? Like Ruby's internal libraries. And what I mean by that is, you know, where in your code sometimes that the backtrace, it really triggered from, right? Like sure, you could be calling some like third level libraries method incorrectly, but it's only because upstream of that, you forgot to use the right object or something else. And because Ruby, you

 

set

 

could,

 

an environment variable that it expected to have.

 

right?

 

I run into that, right? So it's not the code that it's pointing at, it's something else.

 

I hate to say it, but one thing that has kind of obviated that whole process is typing and use of something like Sorbet.

 

I'm sorry, I've got to go throw up now.

 

But it's not without its own drawbacks, but that is one thing that it solves. But also I do wish that the backtrace were a little more clear. I don't know that we can make it more clear without making Ruby less expressive.

 

So I think, so I want to dig at that for just a second, because I think, yeah, there is like a class of problems that Sorbet and other typing systems remove. But for example, I think that Chuck's example is like a really good example of one that it wouldn't fix, right? So when a library has expectations, right, that you aren't meeting, you know, and it isn't a typing expectation, right? Like Sorbet isn't gonna fix that for you or something like that. And that really just comes, in my opinion, that kind of problem comes down to the fact that all over in Ruby we've just kind of gotten... I mean, I think it's always been this way. There's a little bit of laziness, right? Where not in a bad way, just like, I don't know, people just are like, I'm just going to expect this stuff and maybe I don't document it well. Or I do document it. some other library, you know, other people don't catch up, you know, pick up on that. I think there's a lot of ways that you can hit. I think the expectation problem actually is like one of the things that crops up all the time where the error occurs in your code, but it's actually a third party library, but it's really not their fault. It's because you didn't know how to use it, right? Like, and I feel like that is the situation that I run into like all the time, especially when I'm using something for the first or the second time or something like that, right? I'm using an edge case like those kinds of problems like those don't go away because of typing or anything like that Those only go away as you understand what you're using better

 

Yeah, I almost wish there was like some kind of hints framework where if you snap into the framework, you can use some kind of like hinting system that'll just like throw warnings or errors while you're using it and be like, I don't think you really meant this.

 

It pops

 

Why you're

 

up

 

at

 

clippy.

 

it? We should... Jeez

 

Exactly, like CodePilot, but for like, you know, forced assistance.

 

Jeez, while you're at it, you should just have a, you should know what I'm thinking framework. Just to pass,

 

I know,

 

yeah.

 

right?

 

I mean, that is what CodePilot is, isn't it?

 

So

 

I mean

 

a

 

it's

 

few

 

guessing

 

things that

 

but yeah.

 

I'm gonna drop here. So one of them is we were talking about the backtrace and I was working on some code that heavily used begin rescue end. And so they would rescue the error and then move on, right, because

 

Oh, you

 

we're,

 

mean spree? Oh, oh, sorry.

 

no, it's these integrations that we've been writing for my contract. And you know, it's not my choice. kind of hard. So what I started doing is under each rescue, I would actually put E.backtrace.each and then I would print each thing because it gives you an array of strings that give you the backtrace. And so I would just print all the lines of the backtrace and then let it move on, right? And yeah, it's not the way that I would love to do it, but there are trade-offs to switching and it, you know, anyway. So yeah, anyway, so

 

Thanks for watching!

 

that that's been interesting, but it's It's been, it's made it easy for me to start identifying, oh, it hit this unexpected situation, which raised this exception, which got handled here, and then it moved on. But because I can go back through the log, because I'm printing them to the log, I can go through and I can see what's going on. And so if you're running into that, A, look at what you're rescuing and maybe what you shouldn't be rescuing. of information to the console or log or something so people can see what's going on.

 

Yeah. I had an app

 

Thanks for watching!

 

where there were just exceptions, no rescue exception everywhere in the application. There were hundreds of them.

 

Oh, I'm sure.

 

Everything seemed to work, but when you ran into errors, you have

 

Ha!

 

no idea why. And so I proposed like we need to fix this. So we are actually handling these errors instead of just, you know, swallowing them. And so I got some pushback. I set up a slack notification. Anytime one of these errors got triggered, it just threw it into the general chat. And so our chat was just getting lit up all the time with errors.

 

Oh man.

 

And so we actually started going back and fixing them.

 

This seems

 

So.

 

like a social problem, or like

 

Yeah,

 

a,

 

that's...

 

not a code problem.

 

Yeah, it definitely was, but... So.

 

I mean, I agree, right? Like using rescues, using like the rescue end as sort of like a way to path through your code has some serious consequences, some of which have been like sort of brushed upon here. I work on a Spree app, you know, it's one of the projects that I have and Spree does this a lot. And I ended up like creating like custom error classes or whatever. rescuing all the spree errors and like digging out, like pulling the stuff out of them and shoving them into custom errors to throw those instead. Like that was my solution. I'm not even saying that that was great. Cause we're not totally happy with that either, but like it gets messy when you have this kind of a thing and the solutions for it are not pretty either.

 

Yeah. Well, and if you've got an experienced person doing it, there's usually a reason and they, they made a trade off, not always, but often.

 

You know, I

 

I

 

do

 

do

 

want

 

agree

 

to

 

with that.

 

touch on the front end a bit, because I think that's, we're working on Rails applications, and especially with Hotwire, if we're dealing with Hotwire kind of stuff, have your dev console open, because if you're developing something, and if something is not working the way you want, you may be losing valuable information in your dev console, in the browser. And that's especially true if you're working on stimulus or turbo frames or streams, you might be basically ignoring these errors that really are relevant to the issues you're experiencing. And when you're asking for help, the first place you should look is your dev console to see if there's any JavaScript errors. Because if you don't get those resolved, then they may be what's actually the root cause of your problem.

 

Another angle on this that I'm running into with the work that I'm doing is that I'm hitting an API, right? And so, you know, this is data from the back end That you know may not be coming through maybe logic on your front end for that matter But you know, you may just be consuming an API and it's the same kind of thing, right? Finding a way to print that payload you're getting trying finding a way to Open that up so you can watch it go by while you're working useful. But yeah, especially on the front end, I mean, it dumps all kinds of information in the console and you can customize it to dump all kinds of information in the console with console.log. And what's nice about that too is that you're not gonna fill up or, you know, scroll too far past what you needed, like you can on the command line, to get the information you need.

 

I've definitely started wrapping APIs pretty much all the time.

 

Yeah.

 

I've even gone, it depends on the app, of course, but I definitely have a couple apps where I have API, so I have models in my Rails environment and then there's a model equivalent on the other side. And then I have an API model and its job is just to basically understand what it's getting from the API, right? have a way to convert it out. That way, when I have problems or they change the API, it's all consolidated there. And APIs are on another place. It's a lot tougher than it looks to deal with.

 

And not only that, John, but being a third party API, if you're consuming it, you were relying on that company still being there tomorrow. And if they're not and you need to find an alternative, then you don't want to have to refactor a significant portion of your application to then use another technology or another service. Having it all contained within the API model, as you call it, I think is a great idea then you're just having to change one place and it's going to affect everything. And by doing that, you can still have it respond to your application, give the results back in the same format, but you're calling it differently to a different service. So there's definitely multiple benefits in going that route.

 

Well, another form of the benefit you're talking about there, Dave, is that maybe that company doesn't go away. Maybe that's exactly what I was hired to write my code against. But then they come to me and they say, hey, we also want to integrate with this other API that provides a similar sort of data, right? And so you can lift that structure for the one API library and just basically transpose it onto the other one. endpoints and managing the data a little bit different, but you have something that you can immediately apply. The other thing is that any logging or debugging code that you have in there that makes it easier to reason about what's going on comes with it. And so it's not just a question of do I have to change services that I'm connecting to, but it's also a portability issue when you have to connect to something else.

 

Yeah, that stuff kind of works too. I definitely have had a case where the APIs were so different. So I mean, I think,

 

Yeah,

 

first of all, I'm

 

fair.

 

a big fan of this, big fan of this, and I do think it works most of the time. However, I've totally had two APIs that just, you know, one was more restful than the other, right?

 

Mm-hmm.

 

And like, and then that made it really hard for that to work, but outside of weird cases like that, yeah, totally.

 

Yeah,

 

100%

 

but

 

agreement.

 

my point there is you effectively have the structure kind of like what Rails gives you with the CRUD, where it's, you know, I know I'm going to have to retrieve this object, I know I'm going to have to post this object, right? It may not even be the same object type as the other thing, but you've got, effectively you've got your framework together for that stuff, right? And so those operations can all happen even if the endpoints don't look similar.

 

Yeah.

 

Oh yeah, I just meant that like one was like a, they were just organized differently, right?

 

Mm-hmm.

 

And so the other side, in one API I had like models, you know, over there that I could kind of query. And then on the other version of it, there were like events, right? And so then I just, my structure didn't fit

 

Right.

 

so well, but that was a rare case and most of the time, that's not really

 

Yeah.

 

how it works.

 

Yep.

 

And it helps prevent vendor lock-in, which to me is very

 

Yeah.

 

important, but.

 

Yeah, I mean, I would say like the other thing, if you're doing APIs, okay, I mean, I guess, we're kind of off of troubleshooting, but like if you're doing API stuff, the other thing that I found that made my life easier is actually like, is complicated. If things get complicated enough that I'm caring about this stuff, then having like some sort of event system to put stuff like an event-based database, like, you know, that's helpful. shove it all in there and have all of history if I need to like reinterpret, for example, all of the stuff that I'm getting from an API.

 

Yep. Uhhhh trying to think what else I do to troubleshoot stuff. What do you guys do for production or running on a system that you don't own? Because a lot of times, Dave said this earlier, you basically replicate the data, you stick it on your own machine and you run it. But what I'm finding, especially in this situation, and I'm not going to complain about the system that they're using on my client, even though it sucks and is severely restrictive and doesn't need to be. But, you know, a lot of times, you know, we have to run it against third party data. And so it has to be, you know, up where the credentials exist and the data exists and stuff like that. And so it's not something I can debug locally. What do you all do there? I mean, I have some ideas and there are some approaches that we've taken, but I'm curious what you all do with that.

 

charge them more money for making your life harder? I mean, okay, it's gonna take you longer to do it, right? Like

 

Right.

 

I think effectively at the end of the day, like all of the things come down to, it's going to be harder to do it if there's more restrictions. So if you

 

Mm-hmm.

 

are being hired by somebody, that means that you need to charge them more. If it's your own company, then you have to like make choices on whether you think that, you know, now you, I mean, it's gonna cost you more, right? are going to spend more time working on it. But I mean, it depends. Like, do I know? Right? It kind of depends on, like, if I know for a fact that I'm going to have to do this again tomorrow, then I'm going to do some work today to make my life easier tomorrow. Right? But if I don't know

 

Right.

 

that, and I think that it's just a one-off, I may just be like, all right, let me get my credentials out, or something, if that's available to me, right? And do some debugging up there and not save anything. If that's not possible, right? So for example, if I have a system where the process results, so I think Spree is a good example of this. I mean, I'm thinking about a different place where I did this work, but I don't have like, but it was a custom job, so I can't really describe it or whatever. But Spree is a great example of this. through checkout, it saves the order repeatedly, right? So debugging that in production is hard because now you have a real order and there's potentially consequences from that. But if your system saves everything in RAM, it's a lot easier to debug. You might have to copy data. Let's say that you can't get it out of production. You might have to manually copy data or... You know, I mean, it gets hard. The more locked down it gets, right? to a point where you are like, okay, well, I can debug this, but there are consequences. Either I have to copy data out of production because I'm not sure why this is broken, right? Or I have to log into production, which I'm not supposed to be on, and I have to say, hey, I'm creating a test scenario or whatever, right? And go with that. It gets really tough.

 

Yeah, I mean, there are a lot of different ways to address that. I mean, the one that comes to mind is Martin Fowler's event sourcing to snapshot things as you go along. I know that I've used that before in debugging just to capture all of the steps that the code goes through for a specific object, right?

 

So we're at the point where we're adding something

 

Yeah.

 

to our application to capture, you know, stuff for debugging.

 

Right. I mean, going back to the Chuck's question of like, you know, how do you handle like third party APIs or things like that, right? That are systems that are external to your own. I mean, personally, I find myself leaning toward companies that offer products that provide mocking APIs. Right. Where I can literally test it and be able to create my own hooks using their libraries and know for sure, they made the libraries, that it will be as close as possible to production as possible, right? And

 

I

 

an

 

wish...

 

example

 

I wish...

 

of that is Twilio, who provides a mock APIs so that you can create your own web hooks and mock an endpoint from Twilio and get responses. I mean, I know personally in the past, I mean, many years ago now, I wrote one of those in RSpec and it broke maybe a year or so later change their response or something like that.

 

Mm-hmm.

 

But I mean, that's

 

Oh,

 

the alternative, right?

 

I like that as a canary in the coal mine though. You know, my integration code works. It works, it works, it works, it's busted.

 

Right. I mean, it's it's OK, but you

 

Yeah.

 

know, it's the wrong time to get the signal.

 

Yeah, yep. So

 

Yeah.

 

I'll tell you a couple of things that we do. Some of the things we do is just third-party services, right? So they have the logging. Actually, the logging isn't connected yet, but their main primary app that is one of the endpoints I'm hitting or one of the services I'm working with, they have a third-party services that all their logs get sent to, right? And so that's helpful because you can search them, right? skills are okay, but that's no fun. The other one is the bug tracking systems. I'm trying to think of some that have sponsored us recently, Raygun or Sentry, right? Or some. And so, you know, I use Sentry on my stuff. And yeah, you know, if I put an exception in because this really shouldn't happen, if it does bail out and die, then right? out and died. I'll have it throw an exception and I'll catch it. Those are some ways. Often, it's a behavior that's technically legal but is not desirable or is unexpected. Those get harder to deal with. Those are harder to figure out.

 

Yeah, I guess I wasn't even thinking about that because I think I operate off the assumption, right, that everybody is using something like that at this

 

Yeah,

 

point.

 

that assumption would be flawed. And it's a surprisingly

 

Yeah,

 

low

 

I realized

 

number of

 

that.

 

people that use them. I never cease to be amazed at, wait, you don't have this instrumented? Well, how in the heck do you know what's going on then?

 

Yeah, all right. I accept that that's flawed. Yeah, I mean, I definitely operate off the assumption that you're using that at this point. They're so helpful to have. I'm thinking about use cases where you got this exception or maybe you didn't, right? Maybe you didn't catch an exception because it's not throwing an error, right? And you're

 

Mm-hmm.

 

trying to find what the... You have bad data stored in your database now or something like that, right? And that's how you discovered that you have this problem, throwing an error in your error logging system. Yeah. Yeah, that gets tough. So this actually goes back to one of the things. If you're doing this, if your error is coming in from an API, I think one of the things that I mentioned before I think is useful here, which is using something like Kafka or something, store all your events as they happen, and then have a history. of all, you can recover if everything goes really badly and, you know, well, crap, you know, gotta blow it up, right? Let's just replay the whole thing, right? So you have that as your final fail back. But at the same time, you also don't have to replay all of history. You can just say, oh, well, this is the particular event that caused the issue and I can replay history starting from then, right? Once I figure it out and fix the problem. drill down, but it creates a scenario where once you finally figure out the error, which can sometimes take a while with some of these weird things that we're talking about, right? We're definitely talking about non-normal, this happened in production, I'm having a really hard time figuring out what caused it, maybe it's a race condition or something. Then once I figure everything out, I now have to deal with all of the data that happened since that time. Mucking with that when it's a live system is always really hard. So having a way to recover once I finally figure it out, I think is actually important. Of course, Kafka and all ilk like that are somewhat complicated. And adding those to your system, I don't think is something you should do day one. That's something I think you should do a couple of years in when you're like, okay, we've pretty much got all the features done, but now we need a recovery system because we have customers and stuff's going up.

 

Yeah, you know that that reminds me of the Rails instrumentation API. Right where it basically is that signal that you can capture at any time. And that's kind of like a great place to start. I know I've started there before and just hooked into almost anything that I needed as a separate log, right?

 

Say what are you hooking into as a separate log here?

 

Rails instrumentation APIs. So there's one for like active

 

Okay.

 

record if you're worried about the database or model validations or there's like a whole huge list of things you can capture that are just broadcasted.

 

Got it. So you're talking about what, just logging it?

 

or even filtering, like using it as kind of like a place to debug things that are happening in a very specific place.

 

Is it embarrassing

 

I mean, that makes sense.

 

that I didn't

 

Thanks

 

know

 

for

 

this

 

watching!

 

was here?

 

I mean, nope, nope, because I forgot about it until you described what it was, and then I was like, oh yeah, that, right? Because I've literally never used it for this, for sure.

 

Yeah, I mean, there's a famous potato middleware that you can create, right? Where you can capture the rack requests as they come in if you have some low level thing with your routing or something like that. I know I've used that before.

 

I've done that, I didn't realize that was the same thing.

 

I mean, they're very

 

Yeah.

 

similar. I think they it's it's all tied in together with real ties and stuff

 

Well there goes my weekend, I'm gonna play me this.

 

Yeah, okay, so back on troubleshooting. I feel like these are all

 

Ha ha

 

things that happen, right? So we're like totally talking,

 

Yeah.

 

I don't know about you guys, I'm presuming it's the same thing where somebody says something and then I think back to a time when I had a problem, right? And really I'm

 

Mm-hmm.

 

speaking from there, is like I'm talking about all this stuff. And I feel like the thing about troubleshooting is like you, from the basic level, If you can't, jeez, I mean, figuring out where in the back trace your nil exception's coming from, that's definitely day one, step one stuff. Then you deal

 

Right.

 

with third-party libraries causing those issues. That's what I feel like intermediate developers are struggling through. And then, obviously this might happen to you earlier than it should, of course. That can always happen. But then you start getting into things where you're having to with race conditions because you're doing JavaScript on a page or you're probably not gonna have too many race conditions in Ruby but JavaScript all the time or you might have to deal with like you know those API things right like and so these are all I guess I guess we're just talking about techniques and things that you might have to pull from in those cases because that's what bothers us but

 

Mm-hmm.

 

We really were talking about troubleshooting, just we were talking about our own, what we did to troubleshoot something.

 

Yeah.

 

It's all made up.

 

Yes.

 

I mean it comes down to it, you change how you troubleshoot. You know, every time.

 

Yeah, well something didn't work very well last time, so you're like, I don't want to do that again, let me try this other thing. Well that didn't work either. You, yeah.

 

Yep. So.

 

Yeah, I think at the end of the day, troubleshooting is all about getting tools in your toolbox, right? Vaguely knowing how to use them. And then, you know, just trying a tool out, right? You're like, oh, let's see if this helps me to figure out my problem. Let's see if this helps me. And you just go down the list.

 

Makes sense, yeah. And it's just funny because yeah, a lot of this is rather formulaic. It's, you know, try this, look at this. And yeah, then it's down to how things are set up and what you can find, so.

 

Someday somebody will get a Stack Overflow gem that just listens for common exceptions and gives you the answer in a

 

Right?

 

nice little log message.

 

I mean, it's pretty crazy. I feel like when stuff is out for a while, people write these scripts that go and test a whole bunch of commonly found errors. And then they wrap it up in some sort of tool for you. And then we get this. Then eventually that gets merged into whatever this big project is. And then you just get new errors that just weren't included in the old thing, because now you're able to do more cool stuff. your application farther and you're back to square one, which is like all the old errors are gone, but now you're getting new errors because you're doing things that you weren't doing before. So it just doesn't really end.

 

job security.

 

Cool. Any other tips, tricks, things you want to share? All right, well let's do some picks. John, you wanna start us out with picks?

 

Uh, yeah, I'll get us rolling. So, first of all, I had an idea earlier and I kind of forgot about it, but that's okay because we rolled past it. But I mean, I definitely am gonna recommend, you know, pry as always. I haven't checked out Jard yet, so I can't really recommend that, but it does look very fun. if he's doing that. But yeah, definitely big fan of Pry if you're troubleshooting and things. Also, big fan of error logging. I don't know who's sponsoring, I don't know if anyone's sponsoring us or whatever on this or whatever, but like for

 

Nope.

 

me, like it doesn't really matter. Sentry, Rollbar, I don't even remember some of the others, but they're all basically like one in the same, If you need to roll your own, there's Airbrake, E-R-R. Isn't it Airbrake or Airbit maybe? That's what it is. Yeah, Airbit, ERRbit, so you can set up a server and do it at home kind of thing, if that's your thing. But yes, definitely having one of those. So whoever our sponsor is, I guess I'm recommending them. And then

 

Ha ha

 

presuming that one of them is sponsoring us because

 

Not

 

I

 

at

 

feel

 

the moment.

 

like that's pretty common.

 

I'm talking to a couple of them, but the most recent

 

Yeah.

 

ones were Raygun and Sentry.

 

Got it. I mean, I will say that like in my experience, there are differences between them, right? You know, whether that's pricing or like some feature, but you know, for the basic thing, you need to have one of these in your app because I mean, you don't need to have one, but it's so helpful to have one. And it makes it, they do a great job of like consolidating those errors in like one place and just helping you get to the error faster. Right? It's not something that you can't do on your own. It just, it speeds up the process and that's super helpful so I recommend you have one of those.

 

nice.

 

That's all I got I don't have any food things this week because I've not been doing much of that.

 

I smoked a couple of pork shoulders the other day, fed

 

So, nice.

 

60 kids on it. Oh, so good. I love my Traeger.

 

I mean, I've been

 

Anyway,

 

eating, just not been trying to

 

yeah.

 

find good food.

 

All right, Valentino, what are your picks?

 

Yeah, I would go check out RubyJarred. That could be a pick. It's a pretty great debugger. Another tool I use often with just Ruby scripts in general is RB Trace. It's like S Trace, but for Ruby. Pretty great to see all the different method calls that get called throughout your Ruby script. I've used it to debug some kind of weird obscure Ruby stuff. A really great tool. A kind of entertaining article one of my co-workers wrote a while ago, Eric Sellen, he had this really weird issue show up with some of our development environments that we have, that we were moving to the cloud. And we were seeing some packet drops and disconnection issues happening for people that were on one coast or the other of the US. on what end of being the answer. And it's some obscure networking issue and related to AWS. And I think you might get a kick out of it. It's called, it turns out the thought was wrong. 42 is not the answer.

 

haha

 

And the last pick I have is, I'm really excited about the Rails Foundation that just opened up. The company I work for, Doximity, we joined as one of the core founding members and I'm really looking forward to see what comes out of it. It looks really awesome. And I don't know, I hope it can bring some more like educational documentation foundation and make it just easier for people to get started. That's it for me.

 

I'm going to jump in with my board game pick. I've got a bunch. Taught at the board game convention again this fall, and it was fun, and I learned a bunch of games, but I'm not going to pick any of those actually. So we got together with our friends on Sunday night, my wife and I did. It's so nice having teenagers just like, we're leaving, bye! And yeah, we played a game called, what is it? I think it's based on a book or TV show or video game or something. I can't remember. The premise is that a bunch of teenagers go up to the house on the hill and they start exploring it. As you explore

 

you

 

it, eventually you trigger a haunting. The haunting is chosen at semi-random based on how you triggered the haunting.

 

Yn ystod y cyfle, mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

what happens is

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

one of the players is a betrayer, and then

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

the rest of the players become heroes, and the heroes

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

are trying to execute their win condition and escape,

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

and the betrayer is trying to stop them

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

and execute their win condition. And so it goes

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

from a fully cooperative game to a one versus

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

all. And anyway, it was fun. We

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

had a good time. And so I'm going to pick it. It really is that simple board game geek lists it

 

Yn ystod y cyfle, mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

as a 2.39. So it's pretty pretty easy for the casual

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

gamer to pick up and play. And

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

yeah, really enjoyed that. My kids love it. So

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

that's another shout out for that.

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

My six year old likes to be involved.

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

And as long as we're able to tell her what to do

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

and help her read some of the cards, she's fine.

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

She can mostly read the cards and stuff,

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

but yeah, it's just kind of at that level. My 10 year old and all the older kids So I guess he's 11 now. My 11 year old and most of my older kids

 

I'm sorry, I'm sorry.

 

are good playing it. So

 

I'm sorry, I'm sorry.

 

anyway, just gonna shout those out.

 

I'm sorry, I'm sorry.

 

And then,

 

I'm sorry, I'm sorry.

 

yeah, I've got a lot of stuff coming together

 

I'm sorry, I'm sorry.

 

at Top End Devs. Book Club starts

 

I'm sorry, I'm sorry.

 

next month. It's Clean

 

I'm sorry, I'm sorry.

 

Architecture with Uncle Bob.

 

I'm sorry, I'm sorry.

 

And he said that

 

I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry.

 

he's gonna come to some of the calls about the book. So go to topendevs.com slash book club. and the way I've decided to do that is the first 20 people who get in are going to get it for $39 and then I'm going to raise it $10 and the next 20 people, you know, $49, $59, $69. I eventually plan to sell the membership for $149. I am going to have a light version of the membership for like $75 or $100 that just gets you access to fewer things is basically what it is. It's kind of the fundamentals that we're putting out there. Anyway, if you're interested and you want to get in at a super low price, I hate framing it as a Black Friday deal. That's kind of what it is. Go check it out. That's just topendevs.com slash sign up. Then, yeah, we've got a bunch of other stuff coming, but I'm not going to go and talk about all that stuff. I'm also launching another podcast. It's going to be

 

I'm sorry, I'm sorry.

 

Command Your Coding Career.

 

I'm sorry, I'm sorry.

 

I'm going to be talking

 

I'm sorry, I'm sorry.

 

about how to get ahead in your career

 

I'm sorry, I'm sorry.

 

instead

 

I'm sorry, I'm sorry.

 

of having to grind for five years or 10 years

 

I'm sorry, I'm sorry.

 

to show that you have enough experience

 

I'm sorry, I'm sorry.

 

to get the job you want.

 

I'm sorry, I'm sorry.

 

We're going

 

I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry.

 

to show you the other ways to demonstrate to employers

 

I'm sorry, I'm sorry.

 

or your

 

I'm sorry, I'm sorry.

 

current employer, whoever,

 

I'm sorry, I'm sorry.

 

that you have the skills to do whatever it

 

I'm sorry, I'm sorry.

 

is you want. So anyway,

 

I'm sorry, I'm sorry.

 

we'll talk about that and we'll talk about content creation

 

I'm sorry, I'm sorry.

 

and speaking and stuff.

 

I'm sorry, I'm sorry.

 

And

 

I'm sorry, I'm sorry.

 

we're

 

I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry. I'm sorry, I'm sorry.

 

going to be talking about a lot of that same stuff as part of the membership. to the Keepers of the Lost Cities books and I just started the next one it's called Load Star and yeah so far so good. Like I said it's not like the most riveting book that I've ever listened to but it's good. It's good enough to enjoy it and listen to it. So I'm going to pick that and lately I've been watching NCIS and so I'm going to pick that too. All right, well let's go ahead and wrap this sucker up. And until next time, folks, Max out.

 

Take care everybody.