This summer I had the chance to sit down and talk with Noel Rappin about Ruby on Rails, Ember.js, self-publishing, and the benefits of public speaking. Noel’s latest offerings of self-published technical books has brought us Mastering Space and Time With JavaScript and the upcoming Trust-Driven Development.
AB: How long have you been working with Rails, and what got you into it?
NR: Well, I’d been a web developer on and off
since about 1998, starting with ColdFusion as my first tool. I got out of web
consulting for a while and started hearing about Rails around 2007. I was
managing a remote team split between Chicago and Poland, and I started building
up a couple of tools that we could use to collaborate. The first Rails program I
ever built was a little task tracker that you could think of as a very, very,
stupid version of Pivotal Tracker.
AB: There are a lot of versions of Pivotal to be built out there.
NR: Yes! Yes, it was something I needed that could be built quickly, and
Rails turned out to be really good at it. I was already a little bit familiar
with Ruby, so it was nice to be able to write Ruby in a real context. It wasn’t
long after that when I moved back into web consulting and started working with
Rails professionally – and started writing about it too.
AB: You bring up writing about Rails – one could say that you wrote
the book on testing Rails apps.
NR: [laughing] You’re just saying that because it’s called that.
AB: Therefore it is! Right?
NR: Okay. Yeah.
AB: So how has the way that we test Rails apps changed since when you
started working with Rails?
NR: Well, Rails has always had a very strong culture of testing, and one of the
things that attracted me was that the core team put in a lot of great testing
tools. So it had already started from a good foundation, and
there’s always been a sense in the community that testing is the right thing to
do. What’s changed over the last few years is that the tools have all
gotten so much better – and there are more of them. We talk more specifically
about unit tests versus integration tests in a more separated way than we did
when I started working with Rails. I came to Test::Unit first, and then later to
RSpec – after being kind of skeptical about it – and have started using
other tools that didn’t exist when I started, like Cucumber and Capybara.
AB: Is the Rails testing culture stronger now?
NR: I don’t think that the community’s attitude has changed about it, but I
do think that more people in the community are really signing on to what what we
like to believe that we all do.
AB: I remember as a beginner feeling aware of a strong test culture, but I
think it’s a common tendency to take for granted the things that you already
know. You can grow comfortable with the TDD process and forget that some of this
can be really tough for beginners – I remember that phase as a beginner. I go
to meetups and there are a lot of questions about testing. Are we taking it for
granted that we’ve gotten used to testing? Is it hard to test a Rails app?
NR: Well, it is hard to test certain things. I think one of the things I
can’t say that we’ve done is gotten a lot better at explaining how to do this to
newcomers in the community, and I’m probably as much to blame for that as anybody –
AB: Ha!
NR: – but I think that there are two aspects that are difficult. One is
that certain parts of a real application are just challenging to test, and they
often tend to be important parts, like security and third-party tool integration.
Also, for some things there are tricks for how to test them that you
just need to learn, and it’s not the natural red/green/refactor process; that can only
take you so far. Figuring out how to write a good red test
for dealing with a billing system is not trivial, and I think that that’s one of
the problems.
I also think that the message of why you do this kind of thing
sometimes gets a little muddied – this has always been true about TDD
since the term was invented. There’s always been this ongoing conflict between
testing as a tool for driving design and testing as a tool for validating your
application, and I think people who are new to testing can get confused because they’re
actually doing one of those things and they think they’re doing the other.
They’re writing tests as though they’re driving design and they’re surprised
it’s not validating their app and catching all their errors, or they’re writing
tests because they’re validating their app, and the design part of it feels
really tedious. But those are two separate activities.
AB: Absolutely. I think that that’s a very good reflection on the kinds of
confusion I’ve seen with newcomers, where they’re writing a test but they’re not
sure exactly why.
NR: One thing that I think has changed in the community – and I think this is
an outgrowth of now having longer lived applications – is that there’s a lot
more attention to dealing with legacy test suites and a lot more attention to
object-oriented structure. In the last year and a half or so, a lot of discussions
in the Rails comment have come down to the fact that we have to maintain
older applications – codebases that we may wish we architected
differently when they started.
AB: In mentioning Rails Test Prescriptions compared to what you’re doing
now, you have experience on both sides of the publishing spectrum. You’ve done
the traditional publishing company route and also the DIY self-publishing
approach.
NR: Yes. I’ve also gone in both directions in that I had a DIY book that
became a traditionally published book and a traditionally published book that
became a DIY book. [both laughing] Yeah, it’s a little weird.
AB: So how and why did you get started self-publishing?
NR: I actually started with self-publishing. Rails Test Prescriptions was
originally self-published for a specific reason:
I wanted to write about testing because I wanted to write about
something I felt I really knew and didn’t need to research. At the same time,
I knew the publisher I wanted to work with, Pragmatic, was working on an
RSpec book – so I just assumed they wouldn’t be interested in another testing
book. So I decided to self-publish, which I did for about six months,
even though the tools for self-publishing and distributing books when I started
doing this in 2009 weren’t as good as they are now.
It was very, very hard at the time to come up with a place that would easily
distribute digital media and allow you to send updates.
In fact, I actually wound up having to hack my own because there wasn’t a service
that provided that at the time. A few months in, Brian Hogan actually
suggested that I submit the book to Pragmatic, which I did, and they bought it – so
then it became a traditionally published book.
There’s an immediacy to self-publshing that you don’t get from a traditional publisher –
even a really agile company like Pragmatic. I see every time an order comes in. I see
the name of the person – [laughing] – which also tells you that I’m not getting
so many orders that it’s an avalanche distracting me from everything else I’m
doing – but there’s a connection there. Self-publishing is enough of a novelty
that a lot of the people that buy
the book become very invested in its success, and that doesn’t really
happen with traditional publishing.
People have gone well beyond
sending me corrections and actually do copy edits. It’s really gratifying to
have people donate some time to help in that way. You gain a lot of control over
your distribution, your layout, things like that – and you give up some
resources in terms of having access to professional designers and editors and marketing
– so everything is a tradeoff, but I have a lot of fun doing it myself.
AB: Do you have any advice for prospective authors whether they’re pursuing
self-publishing or another medium to get their work out?
NR: You don’t need to be an expert in a topic to start something. It helps, but
it actually helps less than you might think. If you come to something
already as an expert, a lot of times you’ve kind of lost touch with the process
of learning something new, and that can make it harder to get in the mindset of
explaining something to someone coming in cold.
Now, the topic does need to be something
that you become an expert in over the course of working on a book.
Writing a book is a long process, and if it’s not something you’re really
excited about learning more of then the process will be really, really long.
I recommend if you’ve never really done anything like that to start
with something shorter. Blogs are great for this kind of thing – if you set
yourself the goal of doing regular blogging, like “every Wednesday I’ll write
about a gem that I use” or “every Thursday I’ll write something new I learned
while working on my Ember app.” That’s a good way to start easing into the
rhythm of working on something regularly, and it’s also a really good way to
build traffic. One of the best ways to build traffic is to just be there
consistently and get people in the habit of finding content in a particular
place.
AB: I really enjoyed your talk at RailsConf this year where you were going
over some of your experiences with Javascript frameworks. When did you start
giving talks and throwing your hat into the ring at conferences – was it before
or after your writing career?
NR: I had done a couple of talks in grad school at SIGCHI (the computer human
interactions conference), so speaking came
really naturally for me when I joined the Ruby community. My first talk submission,
I think, was contemporaneous with the first
thing I published in the Rails community. That’s something that I really like.
You know there really aren’t very many technical communities that have the kind
of consistent regional get-togethers that Ruby communities have, and to be
able to go and meet people doing the same things and facing the same problems is
really great. When they occasionally let me get in front of a bunch of them and
try to explain something, it’s even better.
AB: I think, for most people, ‘natural’ and ‘public speaking’ are not words
that they put together in the same part of their vocabulary. You should probably
consider yourself lucky in that regard.
NR: You know, it’s a skill like anything else. And
if you’ve done it a few times, you get better at it and are less nervous.
Merlin Mann, the podcaster and writer, talks
about really thinking about the worst things that’s going to happen – nobody’s
going to eat you.
AB: [laughing]
NR: I also was in a lot of theater and that kind of stuff when I was in high
school, and that was deliberately because it was something that made me
nervous. I wanted it to not make me nervous, because it’s a really useful
skill to be comfortable with that kind of thing, in part because so many people
aren’t. Just showing up is a big part of success, and if you’re the person who’s
comfortable getting in front of a group of people, you become associated with
being knowledgeable because you’re communicating that.
NR: With Mastering Space and Time you’ve been writing not just about
Javascript but about a lot of frameworks as well. Are you using some
frameworks that you haven’t written about? Is your writing about a framework
kind of a ‘Noel Rappin Endorsement’ of that framework?
NR: [laughing] It’s an endorsement in that it’s something I found
interesting enough at the time to write about it. I was actually using Ember as
I was writing about it. I was not writing a large-scale Backbone application at
the time, although I was doing some smaller projects with
it.
At the time that I started writing about Ember there
was a huge gap in documentation and that’s much, much less true now eight months
later. There’s Ember content all over the place now. I’ve been asked a couple of
times if I’m going to add something on Angular, and I’m resistant in
part because I don’t really know much about it yet, and I’m not sure that that’s
where I want to spend time next – but there does seem to be some interest,
so that might be something that
I look at.
If it’s an endorsement, then it will usually pretty explicitly say
that in what I write. It will come through pretty clearly what parts I’m
endorsing and what parts I’m not. I don’t think I’m at all shy
when I talk about parts of Javascript that that absolutely make
no sense, and that carries through to frameworks too.
AB: I’ve been getting really into Ember and finding that I like it a lot;
you stay pretty partial in the books in talking about Backbone and Ember –
but would it be fair to ask for your Ember pitch? What
excites you about Ember?
NR: I’m actually really excited about Ember. I think that it’s very powerful,
and Yehuda has gone on record talking about how their goal
was to try and pull the best practices from a lot of different frameworks in
and opinionated kind of way, and I think that they’ve been pretty successful
with that.
One of the things that really encourages me about it is that
they’ve been very, very good at listening to the community that’s forming
around them. Their original router syntax was really, really hard to
work with, and they got a lot of feedback on it and came up with another one that
was better – and got a lot of feedback on that and came out with another one that
was actually even better.
They’ve made a lot of updates to the framework that have been
motivated by people’s experience using the it.
They started from a place of trying to do something really powerful and ambitious, but
they’ve admitted in cases where they were wrong, and they’ve taken things that were
maybe more difficult than they needed to be and put a lot of
effort into improving them. You see that happening right now with Ember Data,
which has some very well-documented limitations and problems, and they’re really
making a concerted effort to polish that up right now.
AB: I was not one of the people who had tried Ember or SproutCore early on,
but in combination with Yehuda’s talk and your talk at RailsConf,
I got the sense that this is definitely a time to try Ember if
you’re remotely interested in Javascript frameworks.
NR: Yeah, it seems like it needs about a year of thousands of developers
building apps on it to really get to where it needs to be. Rails was the same
way. Rails in the 1.0 and pre-1.0 times was obviously trying to do a lot of
things that frameworks hadn’t done very well in the past. It succeeded at some
of them and didn’t succeed at others – and they were also open (for the most part) to
improvements based on the actual community’s
experiences using it. There’s a lot of that process going on with
Ember right now.
AB: I don’t want to lead you into any topic that you don’t wish to discuss,
so let me know if it’s okay – but for a while in the Rails community, there was an
undeniably massive topic: there were these two very large companies,
these deal sites –
NR: [laughing]
AB: – huge Rails companies that were hiring, from the outside perspective,
practically all Rails developers. This has died down somewhat as an issue, but a
couple of years ago this was the hot topic.
NR: Now it’s just GitHub hiring them all, right?
AB: [laughing] Yes. So for people who don’t have that experience, what is
it like to work in a massive Rails company that was basically competing with
another massive Rails company?
NR: I actually feel like I am pretty comfortable talking about this, because
I can be completely up front and say that my experience at Groupon was really
idiosyncratic. I can speak with perfect authority on something that has nothing
to do with anybody else’s experience, and with intermittent authority on stuff
that has nothing to do with me at all.
AB: [laughing]
NR: I joined Groupon as part of a group of developers that came in
when Groupon purchased the consulting company Obtiva, and I went straight into a
role at Groupon that largely involved internal developer training, so I
never had the experience of being a normal part of a regular development team at
Groupon.
I think that one of the things about the way that Groupon was organized – at
least the Rails side of it, and again I’m speaking
from a somewhat outsider perspective – is that they tended towards smaller
autonomous teams.
Teams tended to have their own structures and way of doing things, so
experiences there tended to vary quite widely. Some teams were really
committed to testing and agile practices like pairing, and some
other teams just weren’t.
So there was a very, very wide range in
Groupon. The company – I think for reasons that made sense – was not really
interested in mandating stuff from the top, and for whatever
reason there was never (at least in the time that I was there) a really strong
push for a unification of that kind of stuff. There
were some common tools being used – there was a continuous integration set of
tools built on a Jenkins core that they’d built up that was well suited to
having 250 Rails developers hitting the same codebase, which Jenkins just is not
suited for out of the box. That aspect of it was interesting, but in practice it
tended to be a lot of small teams sort of pointed in the same direction more
than it felt like one really big team.
AB: That’s probably the healthiest way for something like that to work. I
couldn’t imagine feeling like there were 250 Rails developers on my team.
NR: Yeah, and that’s unsustainable. But what’s tricky about that is that a
lot of those teams really were sharing a codebase, and probably sharing a
codebase more efficiently than they were sharing knowledge about that codebase.
Again, I can speak with no authority whatsoever on what actually happened on the
internals of these teams. But it was very interesting to see what Rails
development looks like with that many people throwing code in the same codebase,
and throwing tests in the same test suite, and how you start to control the sizes
of those, and how you deal with situations that the framework really wasn’t designed to
handle.
AB: You have a new book in the works, right?
NR: Yes. Trust Driven Development It’s currently available at an
introductory price, which means that you get the introduction and nothing else
yet. [laughing] The idea to write about software projects is something that I’ve
wanted to do for a long time. We talk a lot about craft as it applies to
how we put our code together, and how we put our applications together – but
there’s another side to that craft, in terms of how we put projects together, and
how we relate to the people that we’re building software for,
whether they’re an internal client or an external client or customer.
There are right and wrong things to do, and there’s a professionalism inherent
there too – and I have
opinions about that. It’s something that I’ve wanted to write down for
a while. Right now my biggest worry is that it’s going to come out as series of
huge angry rants –
AB: [laughing]
NR: I’m taking care to mold it into something that is more appropriately
structured as a book and less like a cranky guy telling everyone to get off his
lawn. A lot of it is about the
relationship between development teams and either the management or the
customers, and how you can build trust. It’s
tricky to write about that and not make it sound like one side or the other is
always right, because of course it’s complicated – and as much as developers have
issues making themselves understood to the teams that are depending on them,
those teams also have difficulty making themselves understood to developers.
It can become a frustrating exercise on both sides, so a lot of this is about
techniques and processes to try and improve the way these teams work together. A
lot of is Agile based. I think that among the reasons Agile processes
work is that they give you a lot of small opportunities to build trust. The Agile
community describes it as feedback, and what that turns out to be is a lot
of situations where you have a chance to say “I told you I was going to do this, I did it”,
“I told you this was going to be difficult, it was difficult”, “I told you that
this would be easier if you did something a certain way, and it turns out that
that’s true.”
At some point in the project, you as the developer are going to
have to go to somebody and say “something went wrong,” “this is a lot more
complicated than we thought”, or “we just made a mistake.” I talk in the
introduction of the book – which is also available online for free right now – about
this being the moment when you’re at the auto mechanic and the mechanic comes to
you and says “you need new brakes, it’ll cost $2000”. Is that a
good price? Do I need new brakes? I have to trust that this person understands
what’s happening and is communicating that to me effectively, because I don’t
understand it myself. It’s incumbent on the mechanic to be right, and also to
explain the problem to me in a way that leads me to that same understanding.
As developers, when we’re working with people that are outside the
development team, we have to have that same ability. We need to be able to
explain what we’re doing, and when things go wrong we need to be able to say so –
and what happens when you say something has gone wrong
depends on how much trust you’ve built up to that point. If you’ve built
up a lot of credibility by doing things well and meeting commitments, then
ideally you have a certain amount of leeway when you need to say “oh, this
is actually more complicated that we thought and it’s going to take some extra
time.” The boy who cried wolf becomes a real issue here. If you always say that
then the one time you really need it you have less credibility when you ask.
AB: Absolutely. I think those are very good topics for consultants as well as
in-house developers – all of that applies regardless of your customer.
NR: Yeah, I hope so. It’s a mix of theoretical stuff about
process and practical stuff – like how to have an IPM that actually is
effective. I’m enjoying writing it, and I’m hoping to structure it into
something that other people will find useful.
Noel Rappin is a developer at Table XI. He is the author of Rails Test
Prescriptions, Trust-Driven Development, and Mastering Space and Time With
JavaScript.