Our friend and colleague, Bradley Schaefer, has recently joined the team at RSpec. I sat down with him and asked him about it.
Erik Schwartz: How did you get involved with the RSpec project?
Bradley Schaefer: I’ve been using RSpec pretty much as long as I’ve been using Ruby, and probably in the last year I started following it more on GitHub and participating a lot on issues, as well as submitting some pull requests. Even though RSpec is a fairly established library, there’s quite a number of issues that crop up, especially I think with so many eyeballs on it, they find every single nook and cranny where a bug could be introduced, so there’s a constant stream of activity on the project.
ES: What’s the mechanism for communication?
BS: The RSpec team is pretty transparent, so almost all the activity goes on through discussion and GitHub issues. Occasionally there’s backchannel communication in the FreeNode #RSpec IRC channel. But there’s also a lesser used private Google group. To be honest, everything goes on out in the open and is discussed via GitHub issues so people in the community can be involved in the decisions. Or, like me, get roped into becoming a contributor.
ES: What are some of the things you have on your plate for the upcoming months?
BS: We're working hard on getting RSpec 2.14 out the door, and we're discussing what will go into the next major version of RSpec 3.0. RSpec follows the semantic versioning system, so 3.0 will give us the opportunity to make some breaking changes such as removing features that have been deprecated for ages.
ES: Any other geek-out items you want to share?
BS: From a geeky perspective, another interesting thing we’re working on actively for RSpec is removing all of the the monkey patching the project originally used to get things like the Should method attached to every single object and things like that. In RSpec 3 we’re hoping that we can eliminate all monkey patching, at least in the default configuration, or some configuration, which right now isn’t really possible. Not only does it pollute the global namespace, but it also has the potential to break down as a technique when you have proxy objects, or other sorts of objects that mask or change those methods. So removing the need for those monkey patches is going to make it a little bit of a better Ruby citizen and prevent other subtle issues from arising. So we’re pretty excited about that feature, even though it’s a pretty geeky, behind-the-scenes, “how RSpec works” feature—it may not be completely visible, but it’s kind of exciting nonetheless.
ES: Have you heard any feedback one way or the other for moving to the new Expect syntax, the new assertions vs. the old?
BS: Yeah, there’s definitely two camps on that, I think. Moving forward, the Expect syntax is going to be the default at some point, whether it’s 3.0 or later on, I’m not sure. But that’s part of the effort we’re doing in order to get rid of global monkey patching. So I think Expect is really awesome syntax because it describes what it’s doing really well, and it allows you to pass in either value objects or blocks that have deferred execution, with a syntax that’s very readable, which I think is pretty awesome. Whereas before, doing the block syntax vs. directly calling should on an object was kind of jarring how different it looked. And in fact I think maybe a lot of people don’t even know that you can defer execution of things for various reasons. One example of it is when you’re expecting to raise an exception when you call something, you can’t raise the exception immediately before you make the expectation known, because then there’s nothing to catch the exception so it just bubbles up the stack, and blows up your spec before you can even say that you’re expecting it. So that syntax is a lot cleaner with the new Expect syntax.
But there’s also definitely a camp that really likes the Should syntax, and it will continue to be supported at least as a configuration option, so if you’re one of those people who really likes that and aren’t down with Expect, you’ll still be served by RSpec.
ES: How do you organize the actual team? How do you dole out responsibilities?
BS: It’s really loose, I would say. Andy Lindeman is the primary resource for RSpec Rails, and that’s because he does a lot of Rails work, he’s intimately familiar with that part of the project. And the head maintainer is Myron Marston and he is in charge of everything else other than Rails because he really doesn’t work on any Rails projects. So that’s why that division exists. And between the rest of us new guys—Jon Rowe, Sam Phippen, and me—we are all a bit undefined right now. We’re free to roam and contribute to whatever interests us, but I actually think I’ve seen all three of us contributing across the entire RSpec project to some degree. So we’re kind of floaters, I guess.
ES: Have you bumped into anyone else in town who works on RSpec? I know David Chelimsky is in town, anyone else?
BS: David is the only one that I’m aware of, and I’ve seen him at the ChicagoRuby meetup, but I haven’t talked to him. But I have not actually met any of the other team members in person, so that’s kind of interesting, I guess, that it’s an entirely virtual relationship. David has stepped down from being the lead project maintainer, I think because he’s doing a lot more clojure work in his day-to-day life. But he’s still involved in RSpec to some degree. We definitely lean on him to get a lot of perspective on historical reasons for things or our thoughts for the future.
ES: I imagine. He was at it for quite a while.
BS: So I’m going to have to hit up a clojure meetup at some point just to say hello to him.
ES: RSpec is a great name for the project, obviously. Backwards it’s “CEpsr.” Do you think you would have been drawn to the project if it had been named “CEpsr”?
BS: I’m actually spelling it out to look at it to see what it looks like, and I would say probably...probably not. RSpec to some degree is cryptic, but I think the idea of talking about specs is really easy, so it has that. But CEpsr...I don’t know what language you’d use to describe that. But specs definitely speaks to the specifications of something, so it also acts as documentation.