All Posts in Bradley Schaefer

May 24, 2013 - No Comments!

New Mugs for Spring!

We've had a lot of hiring activity since the new year. Say hi to the new faces that have sprung up around the office.

Bradley Schaefer, DeveloperBradley Schaefer, Developer

We rang in the new year by bringing on Bradley as a Ruby developer. He’s worked as a software engineer at a Who’s Who of tech firms including Stubhub, AOL, Anything Social, and Bebo. Given this, it’s not surprising that Bradley thinks everyone should get some programming experience under their belts: “It’s not only useful for a wide variety of applications, but it also teaches you logical thinking, humility, patience, communication skills, and tons more.” Bradley also serves as a member of the RSpec team.

Keep up with Bradley on his blog and @soulcutter.

Jon Buda, DeveloperJon Buda, Developer

Very active in Chicago’s dev scene, Jon helps run RefreshChicago, a popular meetup that promotes the sharing of knowledge and ideas in design, technology, usability, and standards. He also helped launch Desktime, a global coworking and shared workspace service. Hit up Jon if you agree that everyone should spend some time in Michigan’s UP, or if you want to hear the tale of his missing uvula.

Keep up with Jon on his blog and @jonbuda.

Jen Mozen, Delivery Principle

Jen Mozen, Delivery Principal

Jen is an entrepreneur and digital media consultant. She studied computer science and has spent much of her career leading agile software development teams globally. In college, Jen developed a passion for getting girls interested in STEM fields and is excited about making software development more accessible to everyone. This past year she helped launch the Chicago chapter of Girl Develop It, a code school dedicated to empowering women to learn how to develop software. She's a self-confessed learning junkie (Coursera, Codeacademy, etc.), avid reader, enthusiastic sports fan, and cool aunt.

Keep up with Jen at LinkedIn and @jmozen.

alex_head053cebAlex Skryl, Developer

Though he originally hails from Ukraine, Alex has been a freelance software engineer in Chicago for the last several years, working for such names as Enova and Trunk Club. Earlier this year he took some time away from his monitor to drive a rented Camaro really fast down HWY 1 from San Francisco to Santa Cruz. It’s possible a speed limit was broken here and there. Alex was recently accepted into New York's prestigious Hacker School, so we're sending him off with warm wishes for a summer in the Big Apple.

Keep up with Alex at his blog and @_skryl_.

Gabriel Gironda, DeveloperGabriel Gironda

Gabriel joins Table XI via Austin, TX, via Chicago, IL, via Harrisonburg, VA, and originating from Sydney, Australia. He enjoys making computers do things they both should and shouldn't do, and finally fills the long vacant position here of "person vaccinated against rabies."

Keep up with Gabriel at his blog.

Lloyd Philbrook, DevOpsLloyd Philbrook, DevOps 

Lloyd lives in Ubud, Bali, Indonesia for now. He mainly works while we’re asleep, making sure that all our servers keep purring along. If he isn't trying to tweak a Chef cookbook or write another bash script to automate himself out of a job, he's at -60 feet hanging with the fishes. We might actually meet him face-to-face one day.

April 29, 2013 - No Comments!

Bradley Schaefer Joins RSpec Team

IMG_1476Our 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.