Collin: 0:00

Joel,

Joel: 0:00

Hey.

Collin: 0:01

we have a guest.

Dave: 0:02

Hi, my name's Dave. How y'all doing?

Collin: 0:05

Hi Dave. Do you want to just give your own little introduction maybe?

Dave: 0:09

Yeah, sure. Um, so, uh, I get called Dave. That's kind of what I go by, but for various reasons I've, uh, my, my public name might be David Bryant Copeland, which is my, my full, full legal name, which I use to write some books. Um, I've written a few books on, on Ruby and things over the years. Um, and, uh, basically otherwise just been a software engineer for the last 20 plus years, had some experience consulting, had some stuff at product companies, a lot of startup stuff. Most recently was at Stitch Fix and then a mental health startup, so I'm currently between jobs at the moment. But yeah, just mostly just been a programmer and a writer for the last several, several years.

Collin: 0:52

Yeah. You have written, you've written so many books. Uh, I think at least seven, seven is how many I had in my outline. There may, maybe there's more though. Yeah. So several, um, over like the last decade or so.

Dave: 1:05

yeah.

Collin: 1:06

And then, so you started 20 years ago. You said, did you, so I guess you probably didn't start with Ruby. Like what's kind of your path to get to Ruby?

Dave: 1:14

Yeah. Um, so I, I have a degree in computer science. I have a master's degree. I thought I wanted to be a college professor. Um, I year into my master's program, I realized I did not want to do that. So I finished up my master's pretty quickly. Um, did some C and C plus plus pretty early and then did some Java during the sort of initial dot com thing back in the 2000. Um, and did, did a lot of Java. Um, heard about rails kind of around. Probably around Rails 2, like, I think when Rails 2 was coming out, that's when I kind of heard about it. And it was just like, this laundry list of annoyances I had with the Java ecosystem, Rails just had an answer that was so nice. And, um, but, it was very hard for me to get a job because I didn't have any experience, so I, um, I somehow convinced Pragmatic Programmers to let me write a book about Ruby command line applications so that could sort of demonstrate hey, I, I know some Ruby, um, I spoke at a few conferences, and then, uh, got swept up in LivingSocial's massive hiring spree of anyone who'd ever heard the word Ruby before, and that's how I got some actual, actual experience doing it, so. And that was probably 2000... 11 maybe and I got thrown into a project that was like I'd never heard of background jobs or rescue or sidekick or any of that stuff before and this particular project had a ton of that and I had to just sort of trial by fire learn a whole lot about um, how to do that. But it was very, it was, it was very informative. Um, so

Collin: 2:46

And, and, and, and now these years later you're, you're, you have a book about Sidekick?

Dave: 2:51

yeah, I mean I, I've approached this stuff like if I learned something that seems useful to somebody else, yeah. I'd like to write it down so that I don't forget and so that maybe somebody else can get some value out of it. So, um, yeah, the, the pragmatic programmers, they've, they've tried to do a mix of books. A lot of their books historically have been really long, like 200, 300 pages, which is a lot of effort to write one of those, especially a technical one. It's, it's, it takes quite a long time. Um, so they've been trying to do these other shorter ones that are like 50, 60 pages of like really focusing on a topic. And so, um, Yeah. You know, as I mentioned, like, after Living Social, Stitch Fix, um, the previous company I was at, tons of background jobs, like, everything was like, wrapped up in background jobs, and I just learned a lot going through the, the crucible of dealing with that in production, so I thought, okay, I think I could capture some of the stuff I wish someone had told me, um, when I first started, and Sidekick being pretty, pretty popular for Rails, um, kind of, kind of fit pretty, pretty well.

Collin: 3:51

Yeah, that, that makes sense. I, I, I'm a big fan of short programming books because, uh, I don't know, it is very difficult for me to read a 400 page programming book all the way through, or, or more. Um, I think like sub 200 is really good for me, uh, for somebody with my attention span.

Dave: 4:09

yeah.

Collin: 4:10

Okay, so you're, you're telling us about Stitch Fix and, uh, Sidekick and this book. So I don't know, what, what kind of things do you think would trip people up that this might be useful for?

Dave: 4:20

Yeah, I mean, the thing that, that I really learned, like, um, kind of being responsible for an app that had background jobs in it, and so, like, before LivingSocial, I was, like, of the mindset of, like, well, I've made my program, I've written my code, the tests pass, I'm gonna hand off... it to the operations team and the operations team will worry about the database connections. And if it goes down, they'll get page. And that was sort of mindset. So living social was like, none of that. It was like you ship it. If it breaks, you're on the hook to fix it. Um, which is a little jarring to go from not that to that, but it actually made me a lot better programmer. Cause then you could see, oh, this, this, this code I wrote that in theory is beautiful and perfect and has these design patterns and it really is elegant, actually falls over in production, doesn't work, and when there's a problem, I can't figure out what it is. So then you change the way that you start writing code. And so for background jobs, it's really... It's very easy to see that because you're running some code. It can't run in the request loop because it takes too long. The classic example is charging a credit card. It takes a couple seconds. There's no way to make it faster. You can't have all of your web servers sitting around waiting for, uh, you know, Chase to charge your credit card of your customers. So you put it in a background job. And then it's running and then how do you know when it's done? What do you do when it's done? What if it goes wrong? How do you know it went wrong? What if? It gets retried automatically and all of a sudden you've charged someone this credit card 20 times and you didn't mean to like there's all these interesting failure modes that happen. Because you've sort of made this distributed system out of a web server that's in queuing a job that gets run on some other server some other time later. And what to do is, I think there's a lot of like clear ways to manage that, but there's, there was not a, I couldn't find a reference that was specific enough. It was like you'd hear, Oh, make your jobs item potent. I'm like, Oh, okay. What does that mean? How do I do that? Practically, you should be monitoring your stuff. Okay. But like how, like what am I looking for? So, you know, after several years of having to actually do it. Um, might be nice to have it written down so someone doesn't have to spend several years, uh, the next time.

Collin: 6:35

Yeah, I guess jobs are a, uh, you know, that sort of background thing is a place where Ruby developers would touch something more like concurrency in a way they would normally don't, right?

Dave: 6:48

Totally.

Collin: 6:49

So, I assume you'd probably run into a lot of the classic challenges you would.

Dave: 6:54

Yeah, and I used to be deathly afraid of it, cause I think early versions of Rails it was unclear if anyone was working to make it thread safe. So I, like, like the, the problem you could have is if I have two threads running, threads share memory, and so if thread number one, changes memory that thread number two is accessing. It can be extremely hard to predict or even observe what happens, but the result can be kind of catastrophic depending on what you're doing. Um, versus what they call process based concurrency. So you're running two different Unix processes that have totally separate memory, even though they're running the same code base. Their memory is separated. So the chance of them like screwing each other up is pretty low, but you're kind of in a degenerate case using double the amount of memory when maybe you don't need to, um, and memory is expensive and all that stuff. So you want to use threads, but then Israel's itself thread safe. It used to be unclear. I think now they've. I've done a lot to make sure that, yes, it is. But then the libraries, I mean, Rubyists love their singletons. They love className. columnMethod and who knows what is happening under there. But a class in Ruby is really an object that is global and has global state and that gets you back to the shared memory. So I used to be very afraid of doing anything multi threaded and I met Mike Perham who makes Sidekiq. I think that's the way to say his last name. And I asked him, because I had done all these background jobs with Rescue, which doesn't use threads. And I, you know, relayed my, like, fear. And he's like, I totally get it, but honestly, I've been supporting Psychic for years, and these problems have almost gone away. Like, you almost never see... Any kind of threading issues, you really should switch to it. So I was like, okay, this guy's making his living doing this and supporting it a lot. He's probably seen more rails apps with background jobs than anybody. So I think that's, it's okay to trust the ecosystem. So then of course you still, when you're writing code, you have to be careful about it, but it's a little easier to manage the code you control rather than trusting the code that you don't control. I don't know if that kind of got it. I was a little all over the place there.

Collin: 8:58

Yeah. No, absolutely. Um, no, that, that may, I'm definitely going to get that book. Uh, that sounds, that sounds perfect for me because it's short and it's on a topic that I would like to dig into more. So it's, it's got, it's got everything. Um, so. So the reason that I originally, uh, was familiar with you, other than maybe we talked on Mastodon actually, but I didn't put the connection together until later, was that Joel had recommended a separate thing that you wrote called, uh, Solid is Not Solid, which... I thought was just great. It is, um, it is, uh, well, it's about how the, there are some issues with the, uh, you know, the solid principles and how maybe a couple of them are in there because like it made the acronym work, um, which I thought was, uh, that, that, that sort of thing and how, uh, You know how maybe one of them, uh, I actually, I actually said this chat GPT. I pasted in the thing and I was like, does this mean I could never change my code? Like, is that a thing? And it's like, no, that, that is what it says. Uh, with the open closed principle, which that, that was a good one. Um, do, do you want to just talk about that and what, what maybe inspired that guy?

Dave: 10:06

I, I don't know how I, I definitely have noticed over the years, most of what Engineers do with solid as they talk about single responsibility principle. Cause it is the most kind of concrete one and it does feel right. And we all kind of know like code that does like too much stuff is a problem. So it feels like, okay, that's the thing we can talk about. But I just found everyone's arguing like, what is the responsibility? And, and, and like, I just saw people just. Getting way off the rails, like discussing the meta concept of like what is meant by this principle and like, there's just no good definition. And so I went back and I read Uncle Bob, Bob Martin, who kind of coined all these principles. I read the paper where he discussed it the first time and it was very vague. Um, decoupled. And you're like chasing, you know, you're, you're chasing code all over the place to figure out what does it do. And like, why did I do all that decoupling? Like, what is that buying me? And there's this other part, this, this sort of counterpoint to coupling called cohesion, which is like you want a bunch of code in a class, for example, to be kind of cohesive. You want it to all make sense together. And it's okay. To have more than one method or have a class is more than one thing. If what that thing it does is cohesive. So you're constantly really trying to balance coupling and cohesion, right? If you have 80 billion things in your class, it's a mess. But if you have only one thing, it's maybe like to decouple and single responsibility principle doesn't help you there. It makes it more confusing and kind of worse. And so then I read the other papers for the other OL IDs it. If, if some of them are nonsense, like the open close principle, but some of them are like uncle Bob was trying to solve a real problem in the nineties about Java and C plus plus that just doesn't exist anymore in a web app or in a rails app or in a Ruby app. And so like, I don't, they don't feel like principles to me, right? They're, they're just like interesting things you could try if you have a specific problem, but probably you don't need them. But people hold them up as this sort of hallowed thing. And so I thought, um, might be good to take a little. Take a little shot, shot at it. Um, which was fun.

Collin: 12:17

So there were a couple of things from that that I, I really appreciated. Um, one was the speaking about cohesiveness because I, so how would I describe this? Uh, I generally speaking am wary of patterns that people apply. That essentially mean I have to go through one or more middle things to make two other things talk.

Dave: 12:41

Mm hmm. Yeah.

Collin: 12:42

You know what I mean? Uh, there is a, I, I, I feel like this is a thing I've seen a lot where there are a lot of sort of imported patterns and architectures and things where it is meant to make things more decoupled in kind of an extreme way like this,

Dave: 12:56

Yeah.

Collin: 12:57

but. does not really put any thought into the cohesiveness side of it.

Dave: 13:02

Yeah.

Collin: 13:02

Maybe because that is a, um, what was I thinking? It's a, you're saying how dry feels kind of, like, solid. You know, it feels like something you could talk about. It, like, makes sense where cohesiveness is maybe a little squishier.

Dave: 13:16

Yeah, yeah. And so you tend to do things that are like a little easier to understand even though they're not necessarily the right thing to do. And there is this pattern running through a lot of the solid principle or kind of patterns. And also like the, the classic designs patterns book also has this, which is like adding this flexibility to your code and agile has a lot of questionable things, but it has some good things. And one of the good things about agile is like, don't build things that you don't know you need because then you're leaving the door open. to address issues when they actually come up as opposed to thinking in advance, Oh, I might have this problem. And a lot of these ways to make your code solid involves adding flexibility. You don't need adding layers of indirection that maybe you don't need or don't help or making your, um, creating like a class hierarchy and an abstract base class to make this one method like configurable when you don't necessarily need that. And it's just odd to me, there's all this stuff that's like making things flexible as a principle, as you should start doing it right now. Like yeah, if I need to make something configurable, it's good to know there's a pattern to do that, but you often don't need to. So it's just kinda weird to me. I'm not quite sure where that came from.

Joel: 14:32

Yeah, I feel like these, a lot of these patterns are often presented quite dogmatically, like, this is how you should do things, as opposed to, like, this is one way you could do something, but, like, it's not necessarily the right thing for your situation. And, like, I guess it's really tempting to try to find those things. But they probably just don't exist. Like, there is no pattern that you can apply in every situation. And

Dave: 15:00

Yeah,

Joel: 15:01

we have to, over a long period of time, and exposure to lots of different things that worked, and lots of different things that didn't work, essentially develop a taste, uh, and, like, a sense that might be impossible to distill down to, like, a simple five letter acronym.

Dave: 15:22

Right, right, exactly. Cause there's this nuance of like, when would you do that? I mean, before we started recording, we were talking about the Rails schema RB file, right? Rails will by default store your schema in Ruby. And the reason it does that is because it can recreate that and there won't be things specific to a database in there. I would almost never use that. I would use the SQL version, cause I want to use the power of my database. But, I can't just say always use a SQL schema file. I really need to say, these are situations where like, Like, this is why, and here's the situations where that will be a benefit, but there are situations where it might not be a benefit, and I don't want to be responsible for you not thinking it through, right? Like, I want to tell you, like, here's the kind of nuance around it, and yeah, that requires a lot more reading or typing or speaking to kind of get the point across versus a kind of snappy acronym, um, which is, which is too bad.

Joel: 16:15

I really enjoyed, um, Uh, a book. I can't remember who wrote it. Um, who wrote the refactoring book?

Dave: 16:23

Oh, Martin Fowler?

Joel: 16:25

My, is it, I, I really enjoyed that book because I felt like that was just, here's like a hundred different ways that you could refactor some code and maybe make it better depending on this, like, whatever. But like, it wasn't like you should always do this. It was kind of. Or at least the way that I took it, it was just like, here's some code and here's some different code that does the same thing. And if you just expose yourself to this, then eventually you start feeling like, Oh, actually, I feel like this would be better this other way. Um,

Dave: 16:55

Yeah, totally. Totally. Um.

Joel: 16:57

one that I like to go for is, um, just thinking about like, how many different files do I need to open up to make a small change? Um, and that's often where I find that solid. Like if you, if you really have like a very solid type architecture, you would end up opening like 14 different files to change this one very small thing because everything is like completely abstracted into different

Dave: 17:20

right, which means that you've kind of, it's not very, very cohesive, right?

Joel: 17:25

right. And you, and you can bring them all together into a simple, cohesive. Um, like object that maybe you, you could say has multiple responsibilities, but all those responsibilities are very crucially related for your application. And so like, they do kind of belong together.

Dave: 17:44

yeah, yeah, yeah, exactly. And that's just such a harder, it's just, there's a lot of gut feel to that. And like, what is a cohesive concept today may not... It may not be that cohesive a year from now and you need, and that's where the refactoring comes in. Like, okay, now I've got six methods in here. They really do need to be split up. Like, how can I do that? Well, you know, like, like you said, refactoring probably has a chapter in there that tells you here's exactly how to do it, um, in this exact situation. And you can, you know, leverage that knowledge without just applying it dogmatically.

Collin: 18:14

All right, so I'll have to read that one next. Um, I think I own it, but it was pretty

Dave: 18:18

I think it's a long one. Yeah. But the long ones, the long ones, if they're written in a certain way, you could use them as a reference. So, like, you could just probably drop in and read a couple of random chapters and let it go for a month or something like that.

Collin: 18:31

When you're talking about jumping between 14 different files to change something, that reminds me of specifically being at one job where I remember thinking to myself, like, going to work, like, because it was one of those, where I was like, well, this is going to suck. Like, as soon as I open my editor, I'm just like, I'm just like, once more to the breach, like, you know, let loose the dogs of war or whatever. Um, but, okay, so that, yeah. So everybody should read that book. I'm a, I'm a big fan. Um, I don't know what, what other you've written all these things. I don't want to just list them all, but, um, I feel like, uh, you have your agile web development and rails is also kind of a recently updated one. I do own that one. I haven't read it yet, but that, that one I think is more targeted at like an introduction kind of to intermediate level.

Dave: 19:21

and the writing on that is kind of making it, keep, making it relevant for new versions of Rails. So, like, I actually worked on it with, so Dave Thomas wrote the original version. Sam Ruby, last name no relation to the programming language, took it over and then for a few of the editions he and I both worked on it but it was like, it's a weird thing to update a book like that because you, you don't want to change a lot because it's working, um, but you do need to change the code because the thing to do in Rails 3 no longer works in Rails 4 or whatever, or the right way to do it in Rails 5 is, is different, um, But it's a long book. I mean, it's 300 some pages and there's like a ton of code in there that all builds on each other and it all has to work. And, um, so it's, it's a weird thing. It's like a lot of work to not make that many changes or like write a chapter. Like, I think I wrote a new chapter, but then it's gone now because the chapter was something about JavaScript. It's like just irrelevant, a hundred percent irrelevant now. Um, but it made sense for like one version of rail. So yeah, the writing introductory material is. This is really hard because it's hard to think how, what are they, what's the reader going to know and what are they going to get tripped up on, especially if you're experienced because it's been so long since I didn't know anything about programming it. I have to really struggle to try to remember what was it like when I was completely lost and none of this made sense. How did I get through it and you know, it's always a development environment. Honestly, usually it's like I think everything's right But like the database isn't working because I don't know what a port is and the ports different for some weird thing Like, you know, it's always that stupid stuff. That is really hard to figure out that Um, trips everybody up. I don't know why the, the dev environment problem has still yet to be solved. They're always terrible everywhere. I assume YouTube had that experience everywhere I've been. It's been terrible. Even when I made it, it was great for a while and then it got terrible afterwards. It's yeah,

Joel: 21:11

Speaking of that, um, you've written a bit in sustainable web development about, uh, how you use Docker for, uh, development environment. And that, I find that very interesting. I think. I've never managed to, or like taken the time to really dig into that and get that all set up. But the, the promise of just being able to have every developer at the company run exactly the same thing, you know, and you've got everything in there. You've got the database, you've got Redis, you've got like everything that is required for development environment. Day one, you say like, what is it? Docker compose up or something. And then you're, you're, you're set. I love that idea.

Dave: 21:54

It's um, yeah, it's one of those things, so at, at Stitch Fix, we did not have that, and at the point where I was about to leave, there's maybe a hundred some, some developers there, and some of them were using some versions of that, and you kind of see like, well, if I could go back in time, and Docker existed back then, this might have helped some of these problems, um, so like, the, the mental health startup I was at, it was just me, so I, I built everything in Docker, kind of like you described, um, We hired a developer. She was able to get everything up and running. She replaced her computer, got it up and running. We updated Ruby. It seemed like it worked pretty good, but that's a data point of, of one. Um, and then, uh, I didn't know enough about Docker, but she left. And then as I was leaving, uh, my replacement came on and it was during the, the Mac, uh, Apple Silicon transition. So I had an Intel Mac and he had an M2 Mac. And it kind of worked, but like not exactly. Some, there was some weird thing in the emulation that didn't work. And I didn't know that you could build a Docker image that had both architectures in it. I didn't, I didn't know to even ask if that was possible. So I definitely didn't know that it was. And so I think that now, I think whoever's working there now is not using the beautiful Docker scripts that I created because they were like, I'm just going to get it working. Um, I've since learned how to do that, but yeah, it's a, it's just like, It's a lot of effort to kind of create a nice user experience around these tools, which like the tools theoretically can, can set that up. But it's, you gotta have someone whose job it is to keep it running and maintained and keep it evolving and keep it good. And on a small team, like you're just not going to. It's just gotta be someone out of the goodness of their heart does it. Maybe when you get bigger you could have a developer experience team that does that. But yeah, I still use it for personal stuff. It does work, I have a bunch of projects where the thought of running NPM install and seeing the thousand things that break just makes me sad. And so being able to do that in Docker and have it not happen that way is nice. But it's probably a little slow I guess. Like I don't use Webpack, but Webpack. Dev server doesn't really work that quickly under that setup that I have, but I don't know. Maybe someone will figure it out.

Joel: 24:13

Have you tried Orbstack?

Dave: 24:16

No. Is that the um, the faster

Joel: 24:20

the new faster one. The new, the new shiny faster one that doesn't have a price tag yet. But

Dave: 24:26

Yeah, yet. I don't know, it's funny, I don't, I wouldn't mind paying for something that was amazing.

Joel: 24:32

Yeah.

Dave: 24:32

But I am a little nervous of like, VC backed company hasn't figured out how to monetize. And then as soon as I get into their ecosystem, they would get bought by Oracle and deprecated or something. I don't know. A little cynical over the years, but.

Joel: 24:45

It's, it's what I'm keeping an eye on, but we're definitely Uh, kind of waiting to see if they come out with some pricing plans. Just what their business model is going to be. It's, yeah, it's tough. Like, yeah, I don't know. I have the same, the same issue with the, um... I'm really getting into a new text editor called Zed, but I again, have no idea how they're going to make money. And I'm like slightly worried that I'm falling in love with this text editor. Like it's going to be taken from me. It's going to be like shut down or I don't know. I wish they would just like, tell us what they're going to do and like, put it, put a reasonable price price on it.

Collin: 25:24

Yeah, no, that was also actually a concern with. Me for Zed also, and I was gonna say it, but then I'm like, I don't wanna make Joel feel bad. Um,'cause I know he likes it Um, but I've actually thought about, uh, Dave, what, what editor, what editor are you on?

Dave: 25:40

I use Vim. Um, I, I had a computer in college that, that was it. It was just Vim. You had to learn that or you couldn't do it. So that's, yeah.

Collin: 25:51

I keep thinking maybe I should really get my setup there and just do it because then I will never have to change again.

Dave: 25:58

it's true.

Collin: 26:00

it's just going to continue existing. Um, but my, the thing with Neo Vim for me was that, um, They make setting up LSP so goddamn hard, uh, it is Such a pain in the ass, um, that I got to that point, I spent like an hour on it, and I'm just like, I don't want to do this anymore, so I did something else. Speaking of, uh, what you were saying, though, about Docker, what I was thinking, that's, that's another thing where I feel like I spent an amount of time on it, and I'm like, is this going to take me like two days to get running the first time? And then maybe lost interest in it? Uh, it seemed like kind of a, am, am I missing something there? Is it easier than I think it is to get up and

Dave: 26:40

what I found is that it's conceptually very confusing. Um, and so when Um, and I'm someone who like, if I go to like stack overflow and I see you run this command and it will work and I run the command that it works, I'm not a hundred percent satisfied. I kind of need to know like, well, why did, why did that work? And getting that answer with Docker is not easy. The, the, the, the names of the concepts are kind of confusing. If you're, I'm assuming they make sense to someone who's like a professional. Technical operations person. I don't know. But to me, a lot of the names don't make sense. The concepts are weird. The documentation isn't that great. But when you dig and you get a sense of the technology underneath is pretty solid, but it's just very hard to figure out. I'm not sure how it works and why it's doing what it's doing and why it's not working. And then of course, because ultimately what it's doing under the covers is downloading these massive images. The iteration cycle is, is slow. I mean, I remember being at a coffee shop one time doing this and I'm like, Docker Compose up! And it's just like... I'm never going to download all of these things over coffee shop wifi. So that means I just can't work on it unless I'm at home and that's just different from a lot of things. But, um, yeah, uh, it's, I, I, I don't, I don't know. I think it's not you. I think it is hard to learn and I don't think the Docker company is doing a great job of making it easy to, easy to learn from a lot of different. A lot of different angles.

Collin: 28:11

Yeah, because the, the promise of it, not, not so much for me in, um, in having the, you know, like thing I can just have contained and easy to run in different systems. What's really appealing about it to me is I paid for 64 gigabytes of RAM and I, I think it would give me the opportunity to use all of them. I think if I got that Slack and Ruby mine at the same time, I could probably use all

Dave: 28:37

it definitely uses a lot of memory.

Collin: 28:39

Okay, so you also do, you have a couple of open source things, uh, and one of them seems like it's fairly, like, it's out there, called GLI, uh, which is, it's a DSL for making Like git style where you can have like commands and subcommands. Um, that makes sense, but what, so I, I noticed that two of the open source things you, you list are, uh, are, um, command line libraries. And then one of the books you wrote was about the first book you wrote was about that, which I was kind of bummed isn't a book you can get anymore because, um, that sounds awesome.

Dave: 29:14

Yeah. You know, they, it's out of print and they basically the deal with them that they're when the book is out of print, then the two things can happen. They can say, do you mind if we have another author take it over and you will make 0 on it or, or not, right? They may or may not do that. Or I own the copyright so they're like, you can have the copyright and do whatever you want to it. So I guess in theory I could take it and republish it. Um, It is, some of it is a little out of date and I do have it on my list to like go back and revisit that because it was, it, it did sell pretty well and it was pretty popular and I do think Ruby is great for any command line apps. Um, so it's on my list to revisit at some point. I just haven't, haven't got to it. I think it's probably more of a more effort than just kind of recompiling it, so to speak.

Collin: 30:02

Yeah, for sure. When you were talking about the, uh, Agile web development book, it made me think you were basically talking about it the same way you would talk about like a legacy application, right? Of that, you know, it's this thing you're, you're trying not to change too much because it's like work, but also, and also it's working. Uh, and, but you are also trying to, you know, get it to where it needs to be. Um, I thought that was really interesting. Uh, how do you, so I guess, If somebody were interested in writing a book, where would you recommend they start? Because the idea to me, I got asked to write an essay the other day for a job. And they were like, it should be six to eight pages for this interview. And they were paying me, so I totally did it. But, uh, which is great. I love it when jobs do that. When they pay you for the interviews. Um, but, my, my immediate thing was that is, Uh, with that was, I don't, I don't know if I have eight pages to say about a lot of things. That's, that's, that's very daunting to me, uh, let alone like 300.

Dave: 31:03

It's weird because like, so these, um, these, what they call express titles at Pragmatic that are like, they want to do something that's like 50, 60 pages. Um, I found it actually really hard to, Only write 50 or 60 pages. Like I had several more chapters of sidekick background up things and they were like, just write this as a blog post and those can be, um, you know, mark marketing content for the book. And I was like, okay, that seems, that seems fair enough. So it can be hard, but I think you got to start with like, you have to like to write and you have to really want to express. Some opinion or information, um, in the written word, like the, the, what, how do I want to say like the, like a book is a, is where you can really just fine tune how you're thinking about something or really get very specific about how something should work or why something is like that nuance we were talking about before you can, the book is where that nuance can be explained. Um, and so if you like doing that, if you have the thoughts there, This It's the perfect format for that, um, beyond. Versus, some people are like, oh, I will write a book on X because that'll be a good way to learn about it. That doesn't work for me, I find that a little frustrating because what happens is you write 150 pages and you're like, well, I need to start over now that I've really learned this thing, um, which is, which is hard. So I like to start from, I know this, so I'm not solving the problem of what's the way to do this, or what is my opinion, or what is the... How do I want to, you know, what am I trying to say? It's more like, how do I get this organized in a way that it lands, um, in a way that as many people as possible could possibly could understand it. Um, and, and, you know, all of that is, you're not going to make a living doing it, so you kind of have to love it. You're going to have to want to do it. Um, and. You know, kind of stick with it and get it and get it done, which can take a long time, but 50 pages can be done in a month. 300 pages is going to take a lot longer than that, even if you know it back and forth, it's, it's still a lot more work.

Collin: 33:05

Do you like outline these things before? Kind of try and collect your thoughts in that way? Or do you kind of go just start writing? Like, what does that even look like?

Dave: 33:13

Yeah, I mean, I know other people do different processes. I, I will start with an outline. Um, and try to, like, I imagine like if I'm in the bookstore or I'm looking at the table of contents. It should say exactly what is in the book and what the person is going to learn. Um, and so, try to make sure, like, everything is in there. And then, from there, I'll start writing. And sometimes you'll go off from, you know, you'll get to the end of a few sections, and you're like, well, where I thought this would go is not right, so I'm going to change it. And that's, that's fine, but I, you know, try to end up where I thought I was going to end up, even if the journey kind of changes. But for me, definitely having an outline, especially if it's going to be more than just a blog post. Um, just, just to keep it kind of organized is, is helpful. Um, but then the writing process, like, I don't know if you've heard of the, the shitty first draft concept. So you just get it, you just get it down and try not to edit, try not to think about it. Just get all the words out of yourself and then you can go back and make it. Make it better, right? It's like the, the writing version of TDD, right? You get the code down. You don't worry if it's terrible, but you get it working. And then once it's working, you can go back and make it nicer. So like writing kind of kind of works the same way, or at least in my mind it does.

Collin: 34:32

It's probably something where if I started doing it, it would become clear what the path would be, uh, because I do like writing blog posts, uh, however, I get to a certain length of about a thousand words or so, and I'm like, and that's it, I'm done. And then that section is like, conclusion, I'm done, and then the blog post is over.

Dave: 34:51

Having a time set aside, like, if you can fit it into, it's like any habit, like if you can fit it into your day so that you're like, now is the time when I'm writing, and it doesn't feel like this extra exhausting thing you have to somehow fit, that can help. Um, yeah, I, uh, the first one I did, I didn't, I just did it every moment. I had and, um, you know, my wife was like, Hey, should we do something? I'm like writing Kent, you know? So then I realized like I wake up earlier than her. So I would just do it in the morning before, like I get up, have breakfast and do my writing and then she would wake up and then we'd hang out and then both go to work and that, that worked better. So then I never worried about, am I going to find time for it? Cause I knew I always had that. Time set aside, took a little bit of the stress off, but it's still like you're reading a hundreds of pages every week to like read what you wrote over and over again to make sure it makes sense, make sure it's good. Um, I mean, at least you can do updates to books, but you know, like, I mean, Joel, you just held up the paper version. Like that's not getting updated obviously. So I have to try to make that as good as I can cause I know someone's going to have that physically in front of them and I want to not be. Totally embarrassed by what they bought.

Joel: 36:03

Yeah, I, I feel like when it comes to writing that I feel like I'm missing a bunch of design patterns that writers must have that I know they must have because I know what that that's what it's like when you write software. And like, I, I feel like I'm a junior programmer trying to make my code work and I'm just missing all of these tools that must be out there. Um, and I just find, I find it incredibly difficult. Like, I've... I'm trying to write a book at the moment and I'm finding it incredibly difficult to figure out, like, when I've got multiple concepts that, like, depend on each other, how do I present one of those concepts, um, without the others? Like, which one do I, which one do I present first and how do I, how do I build up to it? Like, how do I organize this so that you understand what I'm talking about when I'm referencing all of these different things? Um, and there must be the tools that people use that they kind of, like, could apply. To that problem, or whatever, or whatever problem you have.

Dave: 37:05

Yeah. I mean, work, so working with the publisher, they give you what they call developmental editor. And so that person is kind of gives you feedback along those lines and they're often not, I hate to use the word technical or not, but they're often not programmers. Or if they are, they're often not familiar with whatever it is you're writing about, but they can follow it and they can sort of figure out if things don't make sense. And they can be this sort of like the smartest, dumb reader of your book. So they can ask questions that are like really helpful and get this feedback. And I mean, it can be sometimes hard to get feedback about, I mean, I don't know about you all, but my experience in programming is you don't get a lot of feedback and it's not often very critical. And so when you do get critical feedback, it's kind of unpleasant, but. You will get it and it makes it better and so they, that helps a lot, um, I think like the most specific thing I can think of that's along those lines is like, go slower than you think you should. Um, don't, don't use words like this and that and thing and it's like use the actual word because the reader is going to forget what, what you're reading. Like just, just assume that they are remembering way less than you might think going through it. Um, and then tell them what the code is going to be before the code, not vice versa, which was, that was the hardest one for me cause I'm. It's easier to say, here's the code. Now let's talk about it. Cause that's how you work, right? You write your code and then you have like a pull request review or whatever. But like a lot of times if the code is too long, like more than a few lines, it can be really confusing if you're just learning. So you have to say, all right, we're going to do this. Or if you want to talk about a 10 line routine, you may have to say the first three lines, we're going to do this and here's why. And the first three lines and now we're going to do these and that going slower, uh, does help it. I, it was not natural to me. Um, but it is better when I look at. Like when I've changed to do that, um, but just having the feedback and someone else who like can help us is nice. Doing it alone is hard cause you got to find some way to get feedback and not everyone's going to, Oh yeah, I'll read your 300 page book and give you notes. Like no one's going to do that, but I'd be happy to look at whatever you're doing. I do like doing it. So if I can, I love helping people, right. And so if I can, if I can help them happy to do it.

Joel: 39:20

Thank you very much.

Collin: 39:22

So, so when we were asking you, uh, about, you know, things we may talk about, uh, one of the things you, you, you threw out a couple of bullet points in an email, and one of them was always up to talk about rails and not putting business logic into active records. So, uh, I, I don't know if we will have extremely different opinions than you on that, but I am interested to hear what yours are in case one of us does.

Dave: 39:48

Yeah. So, um, I w the first rails up, I worked on was a monolithic rails app. And they, they did what seemed right, which is app models are your model driven development models of your domain. So therefore you should put your business logic in those models. And if some of them happen to be also a database table, well, that's just. Part of rails. Um, it was a disaster zone. I mean, it, it was just absolutely horrible. Um, working in it was unpleasant. The use, right? Every, every app has their one model, usually the user, but some model that's like used by everything that's like related to what the app does. In this case, the user, I mean, it had like the first 50 lines were includes of modules and those modules were hundreds of lines long. I mean, the, the user object probably had thousands of methods on it. It was just untenable. Um, Does that mean that conceptually putting code like that in there is wrong? I don't know. Um, but talking to other developers, they had had similar experiences. And so at stitch fix myself and another developer, there were there early. I mean, we were writing, we were, we were saying the exact same things to each other and we were like, let's just not do that. Let's just just not do that. See how it goes. So that's what we did. And so In, if you want to make logic, we decided we put it in app services to have another place for it. That would be very obvious that that what that was for. And that's just where that stuff would go. And you just make a class, right? It'd be called whatever user creator and had a deaf create, like just don't think too hard. Just put the code somewhere else, literally anywhere else. And let's see how it goes. And it was, it was nice. Um. The, those classes were not large. They were pretty easy to understand. Um, and what I thought was really interesting was as we hired more developers, um, I don't remember having a lot of conversations about like, you need to write the code this way, but people just did. Um, and that told me that there was some value in doing it that way. Now, maybe. Someone at GitHub or Shopify or Basecamp has some secrets for how to avoid that mess that I was talking about. And I'd love to know what that is, but I've never heard of, I've never heard of anything like that. So, um, that's kind of a super kind of pragmatic practical reason why I go down there and I can. I have some retro, retconned reasons why I think it works, um, but that's kind of like how I got to it, and I was just very happy with that, and other developers seem to be, so, I don't know. But again, this is one experience for one person, so, uh, who knows what cosmic forces might align elsewhere to make this a bad idea.

Collin: 42:29

Yeah, I'm interested to hear what you have to say about that, Joel, because I think my thinking may be clouded by not having worked on as many really, really large Rails things. Um, but, uh, but you have done more of that, so I'm curious what you think of that.

Joel: 42:45

Yeah, this, this is a tricky one. I think, um, I'm always torn between, uh, feeling like, like, doing too many service objects overcomplicates things, and means that you have to have... Like 14 different files open when you're trying to make one change. Um, we talked about earlier in the show, I think. Um, and, uh, I think like I, I, I, one alternative approach is just try to model smaller things. Um, and if you're, if your model is like thousands of lines long, there are probably smaller concepts that you can extract from that model that themselves are significantly smaller. Um, like. And, and maybe this is just another, another way of approaching what are essentially service subjects. But like, one example is instead of, uh, having like create user as a service, you could have a user creation as a model. Um, and like, it's kind of almost exactly the same thing. You're still breaking it down, but you're just trying to. Your user creation doesn't necessarily, um, this is probably not very great example, but it does, these other models don't necessarily do just one thing. They might be doing two or three things that are related to the two or three attributes that they, um, kind of manage. They're like these simple kind of value objects. Um, so I kind of try to think about it like that, um, is like, if I can take these. These three arguments that are being passed around, turn them into an object. And then anything that is related, like things that we apply to those three arguments, those three like objects together, we can model in that model. Um, as long as it has a, you can come up with a good name for it. Um, so I do, I think that's another approach and I don't think it's. Completely opposite to service objects. Um, but I think that my understanding is that service objects are more about like, try to take every action that you can do and make that be like, it's essentially like a callable object, like an, an event or a

Dave: 45:10

Yeah. Yeah, it's, it's interesting. Cause like you're, you're getting across sort of two concepts, which, which always make this topic hard to talk about. So one is what you're is like, okay, if we're agreed that our methods don't have to go in the active records always that we could put them in another class, that's one thing. But then the second part is given that what's the structure of all that. And for me,

Joel: 45:33

Exactly.

Dave: 45:34

The structure of all that is less important than just don't put it in the active records. Like, I feel like if the, if it was called app active records, we would never have this discussion. Cause those, those, those active records are, in my mind, they're models of a database table. And they're great models of a database table. But like, the, the create method of my user active record is not where you implement the business process of what happens when a user gets created. You could. But I don't think that's what that's really, really for. Um, and so where that goes, I think like what you described makes a lot of sense. I've seen that seems reasonable. Um, I, I'm not a big fan of the make every method called call, but I've seen that too. That's another thing. So it's, it's hard to pick it apart, but the, and I guess maybe, you know, I was saying before, what does Spotify and GitHub and Basecamp do? I think you've seen what Basecamp does and they just make a bunch of modules. That do that and they include them in whatever active record makes the most sense to them

Collin: 46:34

That, that has been my impression from, uh, from reading things.

Dave: 46:37

Yeah I absolutely hate that, it just drives me bananas and I don't see the value in it, but obviously it works for them, so that's cool, so that's one way to do it. But other than that, I don't know, I feel like if I could just wave a magic wand to every Rails developer, it'd be like, just don't put that code in the active record. Put it literally anywhere else. Don't put it in the controllers either, but you know what I mean, like don't put it in the active record. But having a, um, Having a way to, like a, a, a pattern is, is good because you can also do like, like if, if half your team does what Joel, you were saying, and the other half does what I'm saying, that's kind of worse in a lot of ways. So you don't want that either. Um, so you need some, some guidance.

Collin: 47:22

I, I do think some of this is just clouded by not having worked on as many really, really large Rails things. But I, I do want to kind of, when I think of like cohesiveness, right, I'm trying to keep the, this may be the mistake your coworkers went down though, uh, where you were saying like they started off with like a good thought of like, this is our domain object, so it should, uh, It should build off of that, that, that intuitively makes sense to me, um, although I can, as you say it, I do understand that doing something different, my thing is always like, the interface may be there, but like, what's behind that interface is pretty flexible, um, so I don't know. Like, I wouldn't literally have all the code in those modules, like they probably would still be using other objects and stuff, but they, but I may, it does kind of make intuitive sense to me to expose a lot of that through there, although I do understand what you're saying.

Dave: 48:24

Yeah. I mean, another angle I think about this too, is like. If you're gonna write, if you're gonna change or add some code to the app, like how many decisions do you need to make to figure out where that code goes and what it should look like? And ideally it's zero. You just know exactly where it should go. Um, not ideally it should be a lot like, okay, should this be in a module? Should the module delegate to an object? Should it go on app services or app models? Should it be in a namespace? Like you wanna minimize those or make those decisions like very, very easy to kind of arrive at. Um, and for me, like the stupidest, easiest way is like, just put it in app services and make a class. You could figure it out later. Um, but it to, to your point Colin, it, it looks ridiculous at a small rails app to go into a controller and have it be like user creator create, and then the user creator create method is just user create. That does look ridiculous. Um, and so someone seeing that would be like, what is going on here? This doesn't make any sense. Um, so it, it, it is, it is hard to kind of make the app look the way you want and be easy to work with for you know, the size that you're at or the problems that you're trying to solve. And you know, that's the that's the whole problem with it, I guess.

Joel: 49:40

It really does depend on the size of your app and, and your team, I think. Like if you have thousands of developers working on, you know, an app with millions and millions of lines of code, then that pattern is not going to look as ridiculous, like, you know, that because creating a user is going to be doing a thousand different things. It's not going to be just delegating back to the user model. Um, so I fit, I think that there's, it's not like. It's not like a binary thing. Um, and sometimes it might just be a case of like, if you have this model, that maybe your user model usually is the user model is getting out of control. Then start there. Like if that's a problem, then start extracting things, make, make things smaller, um, try to figure out what, what ways you can group things up. Um, And, and yeah, the thing, the thing for me is like thinking about, um, thinking about events as objects as well. So like a user creation is. Is an object, whether, whether you make that like a service that's create user or a model, which is user creation, you're still essentially modeling an event and it's okay. Like that is just that idea of like, I can't find the right model. I can't find the right model. Well, maybe the, the thing that you're doing is. That's the thing you're trying to opt to model. Um, I think that idea can be really, really helpful.

Dave: 51:19

Yeah, it is interesting how If you fit everything into an event kind of thing, like they all, they all kind of are right. It's, it's pretty easy to, to, to think of stuff like that. Um, and yeah, that can be. We, we did some of that at, at Stitch Fix. And it, and it, it, it helps to decouple things that don't need to be coupled together.'cause and then to come back to background jobs, right? A background job is kind of like, here's an event and you kind of launch it into the ether and like, it has to be decoupled because it's, it's lost all the context of the controller method that it was in. And that forces you to, or requires you to, to write the code in a certain way to, you know, to make sure that's manageable and, um, yeah. Um, And hopefully there's someone on the team who's, like, thinking about that and watching it and knows, uh, this looks like a mess waiting to happen, let's spend some time cleaning this up, um, and everyone is like, yeah, we should do that, or, you know, we don't feel pressured to just keep shoveling things into the mess and worrying about it later.

Joel: 52:19

It's, it's so easy when you have a file that has like 6, 000 lines in it and you like to just add three more,

Dave: 52:28

I know, yeah,

Joel: 52:30

you know, um,

Dave: 52:32

I mean, we haven't talked about CSS, but there, there is a CSS file at living social called JSIO dot CSS. And that's where all the CSS went. It was an append only CSS file. It was thousands of lines long. And I was like, what is, what is, why is it named that? It was stood for just shit it out. Because there was like this, this sort of ethos of the company that was like, try everything, just, just shit something out really quick, uh, to see if it works product wise. And I guess that was applied to the code too. Let's just just keep throwing it in there and we'll worry about it later. And this is wild. Sorry for the bleeping you're going to have to do. I trying not to use too many curse words, but

Collin: 53:09

Now we're definitely not going to do that. Um, but, uh, the, um. Man, when you say that of the, the, the just shut it out file really makes me think, I don't know, maybe I will try to have one. Maybe they have a point.

Dave: 53:22

it is nice not writing CSS. It's one of my favorite things to not have to write.

Collin: 53:27

yeah, it's, I, we don't have to go into CSS now, but I, I, I am conflicted. There are many approaches and I've, uh, you know, I don't know, I guess my briefly, uh, I guess maybe it applies to a lot of things is that, um, yeah, at a certain scale, anything works. And I think that applies to like. Putting stuff into your records or that fit small enough scale. It probably really doesn't matter what you do So yeah, I guess the answer to every question is like it depends

Dave: 54:00

And honestly, like if you have a team who like doesn't want it, like really wants to write a semantic CSS or really wants to put stuff in active records, that that absolutely counts. Like, why would you make all those people miserable to do some other pattern that they don't want to do, right? They're the one, it's their job to work on it. And if they want to work a certain way, that's probably, that counts a lot. Um, for what you want, what you want to do. Especially when there's things that are like, kind of stylistic. Like, is everything call? Or is everything an explicit method? Do we put our, are we using BEM for CSS? Or are we using Tacky? There's not a sort of like mathematical proof of those being better than the others. So, the feelings of the people doing it, like, have to count. Um, cause there's no reason to be miserable at work, or at least, you should be not as miserable as you can, right?

Collin: 54:53

should be not as miserable as you can I definitely agree with that Yeah, that's a good one well that being said then I think it's a great place to wrap up But we'd love to have you back when we think of more things to talk about For now, do you want to tell people where to find you?

Dave: 55:11

Yeah, um, I'm on Mastodon on ruby. social slash davetron5000, um, davetron5000. com is my website, it will redirect to the less easy to spell naildrivin5. com, so just go to davetron5000. And that, that's, that's where, those two places, Mastodon and my blog are usually where I'm at. And uh, if you're into background jobs and sidekick... The book will come out of beta at some point and therefore be 100% perfect with no errors at all, and you can safely buy it, uh, 9. 99, pages of quick read, I hope.

Collin: 55:44

Amazing. Well, uh, well, if you're, if you're listening to the show, you like the show, please tell your friends, rate, subscribe, star, uh, create a background job to, uh, post about it. Um, and, uh, we will talk to you next week.