Zach Dennis

Hi, I’m Mikey with Uteastic. I’m here again at SCNA. So I’m sitting down with Zack Dennis. Zack has an interesting story. He’s a contributing author on the RSpec book, but he’s also not on the RSpec team. So how in the world did you go from not being on the RSpec team to contributing to the RSpec book? Well, a few years ago, I had been doing a lot of Rails development and had really kind of latched on to RSpec and its philosophy, that kind of the language you use influences the way that you think about the world. And I was just a very active community member on the RSpec line list in terms of how to apply different testing practices with RSpec to different parts of Rails applications. So you were looking at, you had applied RSpec, not so much like thinking about it, but how do I make it do what I need it to do? Yeah, testing in the Rails community was still pretty new, and I was, I think, in at the right time to contribute a lot of ideas to the community. And I think David kind of saw that and at one point reached out and said, “Hey, I’m working on this book. I’d like to get finished. Would you like to include a section on Rails? Would you be interested in contributing?” And I kind of went from there. Yeah. So it’s kind of interesting from his perspective that he didn’t just collaborate on the project and write the book as a vanity thing. He sounds like he approached writing the book in the same way he approached working on RSpec, that it was a collaboration and that, you know, many hands make a good stew. I don’t know, I’m reaching for an analogy here, but so it was like he was very welcoming of contributors, even people who weren’t necessarily going to write a new template. Yeah. So, you know, I think it’s interesting to see, you know, one of the things that David wanted to do is he wanted to do a test assertion example library or something. Well, at that time, that was before RSpec 2 came out, and before that, I think, RSpec really got the refactoring that David wanted to put into it. So now there’s several projects, you know, RSpec Expectations, Monix, Core, all of those things. So RSpec was still like a monolithic codebase at the time, and I think that he may have been actually like the maintainer and the only core committer at the time. Oh, yeah. He had brought in patches. But I think it’s more recent that more people have been brought in kind of as core committer to RSpec. But when he actually started the book, not to give too much information away, he actually didn’t start the book. It actually had started before he took over RSpec. Oh. At least the idea did. And then when he became the maintainer and kind of the author of RSpec as we know it today, you know, he was kind of leading the charge with this book. And it was a lot of work, took a lot of time. And I think that’s, you know, my impression is that’s when he reached out to people in the community, people he respected. Delegated more. Yeah. And he had his – he looked over the, you know, the entire thing. So it wasn’t that each person kind of did their own thing and then that was it. You know, David was definitely the consistent voice and theme throughout the entire book. It was his book. But everyone else, you know, definitely contributed ideas in large sections to their respective parts. And what was your section again? I worked heavily on the Rails section. Okay. The Rails integration or – Just I think the last section of the book is just kind of RSpec and Rails. And it walks through kind of outside of using Cucumber and WebRat. And Brian Humpkamp actually worked primarily on those. And then it got into, you know, Views, Models, Controllers, Hubbers. And those were the chapters and sections in everything. Because what I think is really interesting about your story is that – it’s not necessarily the person who – the thing that makes these projects good and it makes them community projects is it isn’t just contributions to the code or to tasks or to docs. It’s sometimes it’s ideas that are fresh or ways of looking at the way it’s being used and, you know, articulating their facts to the person who’s creating it. So it has kind of a life cycle. It comes out of this person creating it. And then you feed that into them so that way they can adjust or update and then – And then there’s a lot of ways to use RSpec. And it’s impossible for one person to be intimately familiar with all of those different contexts where you’d use a tool like RSpec. And I think that’s one of the reasons why David Proverage talked to myself and to Brian was that we had been doing a lot of Rails work. And I don’t know at the time, you know, where David was in terms of RSpec and Rails. But we had been doing a lot of that. Brian and I had. So I thought, you know, that was something that we were able to bring to the community and bring to the book. Okay. Well, thank you very much for taking the time to sit down with me. Thank you.