Rails Underground

A Chat with Dr Nic

I again had the opportunity to chat with one of the speakers we've got lined up for July. This time, it was Dr Nic Williams - iPhone and Rails expert at Mocra, open source developer and blogger:

MC:I think I should point out to readers that its outrageously early in the morning over there! Thank you for taking the time to answer a few questions!

Dr Nic: I am awake before my two children. I think I get a prize for this. Talking to you is a pleasure.

MC: Can you tell us a bit about yourself and your ruby work?

Dr Nic: I'm one of the world's best looking Ruby developers. I come from a small island nation filled to the brim with outrageously good looking people, called Australia. We've learnt to harness our aesthetic awesomeness into our craft of writing Ruby code.

For me personally, I think I've written 50+ ruby projects - rails apps, rubygems, textmate bundles (that use Ruby inside) since I first went to RailsConf in 2006. The whole "Ruby" thing has unleashed a wave of creativity in me which I am loving.

MC: And what is it about rails that you like so much? What would you say are its best features?

Dr Nic: You do less thinking about non-application code. No thinking about where to put your next file. No thinking about how to write SQL. No thinking about if/how/when to write tests. And I like the Ruby part of Rails a lot. Its a programming language that demands that you write awesome code. Oh and these days you've got Passenger to love about Rails too.

Dr Nic, one of the world's best looking Ruby developers, strikes a pose.

MC: A big message since the early days of rails has been about standardisation. Where the files are, what code to write, etc, and the rails environment is still really good at guiding developers into good development practises. Rails 3 seems to have a shift towards modularisation, and making lots more components replaceable. Do you think that will change things?

Dr Nic: To be able to easily replace chunks of the Rails stack with alternates - either performance improvements or new DSLs (e.g. haml over erb for templates) - will be a tremendous boon for advance rails developers. It won't affect the lives of new rails developers. They'll install rails, run "rails my_project" and have a happy life with the defaults.

With Rails 3 promising to have clean internal APIs it will offer a new era of plugins that can confidently extend rails today without fearing those plugins will break in rails 3.1 or 3.2. Nonetheless, plugin creators should test their plugins against multiple versions of rails, say with the garlic project.

MC: Yes, there are lots of things to look forward to in Rails 3 - what is your most anticipated new feature? And is there anything you'd like to see in rails that hasn't made the shortlist yet?

Dr Nic: I'd like RJS removed as a plugin. I don't think this should be the default way to add JavaScript/Ajax to an app. Its not that the RJS helpers are bad; rather, after you use them, and you then want to write some more powerful/different javascript, what do you do? You either write nasty amounts of Ruby-cum-Javascript in a RJS template, or you break out a javascript file and write javascript yourself.

The latter is more preferable - you are writing javascript in its own language, you can unit test it with frameworks like http://jsunittest.com or Screw.Unit, and you know that the rest of your app can function without javascript. If you are using RJS then its very hard to unit test. I don't think anyone has ever bothered to write some RJS in a TDD fashion. That is, write a JavaScript test that says "this DOM element should disappear" and then write some RJS to do it. You just can't because you need the rails stack to render the RJS.

Its much cleaner and more powerful to start and finish with pure JavaScript, write unit tests for it, and do it in a purely unobtrusive way rather than RJS.

The bestest new thing in recent rails versions is Rack. Rack gives the Rails stack more power. Stackable middleware, low-latency metal endpoints. Its great stuff.

MC: On a JavaScript related note, are you a prototype or a jQuery guy? Do you have a favourite set of plugins/gems that you use when setting up a new project?

Dr Nic: jQuery. I just like the API: an object representing a bunch of target DOMs, and you do things to that group. Or you filter it to get a smaller group, that you do things to. It just seems to work cleaning.

Oooh, rails templates are a very nice addition in rails too. My set of default plugins/gems includes cucumber, rspec, machinist, some jquery assets, will_paginate, state_machine, rails-footnotes, faker and fakeweb.

I think they're documented inside our Mocra rails template at http://github.com/drnic/rails-templates/tree/master file mocra.rb its still a work in progress, but I love that I can "document" my list of plugins and it becomes a live "new project script"

MC: I imagine you've submitted patches to most of those? You seem to delve really deep into the components you use, and do a lot of open sourced coding.

Dr Nic: There's a pretty low barrier to patching other people's stuff these days. GitHub is an open source community's wet dream I like reading through other people's code. Since most of my Rails career has been as a solo developer/consultant, until about 6 months ago when I started hiring, I've read open source code to learn style, tips, tricks etc. So I'm motivated to patch other people's projects - it gives me an excuse to crack open their code and have a stickybeak inside.

MC: And your team at Mocra seem to be like-minded - how have you found growing your business?

Dr Nic: Unlike open source projects, customers needs/desires aren't publicly visible on a website. I'm relatively new at building relationships with clients a level above the code. It helps that I'm outgoing, but I do forget to do some of the business-building activities that pure business-focused leader would do.

Instead I still get lost in code for days or weeks at a time. Since all the mocranites are open source, hacking junkies like me that means that we all suffer from the incurable disease of "this can be fixed with code". I think, tragically, some things can't be fixed with code. So I'm still learning the softer sides of business Mocra has had some great successes in its short 6-month life.

Oakley's Surf Report has been a very well received iPhone application that is featured on all demo iPhones and is being included in an Apple TV commercial. And recently we went live on http://orchestrateapp.com. Finishing projects like this as a team makes being a software hacker a very justifiable career.

MC: I'm just going to sneak in one last question before we run out of time....

Dr Nic: My wife tells me we ran out of time a while ago, but let's not worry about that for the moment.

MC: In the current economic climate, do you think rails has advantages over other frameworks?

Dr Nic: Oh shit yes.

Tough times are when start asking the big questions: what tools and processes can be use to get this job done with less (staff, time, resources)? Agile development means you get the core 80% done with 20% of the "normal" belated effort of a traditional, over-running project. Rails is still the best web dev toolset for efficient, rapid web development.

Rails developers and agile development thought leaders need to be shouting this stuff from the roof tops. Or rather, from the boardrooms and sales calls. Similarly, developers in all fields should take the time now to learn Rails and learn the basics of agile development now so they make themselves more valuable. Its exciting times, really.

MC: That's brilliant! Thank you (and your wife) very much for your time, it was a real pleasure chatting to you!

Dr Nic: Thanks for asking questions that I had answers to. I'll see you in London.

If you found this interesting, I came across another great interview with Dr Nic at Ruby Learning, and, of course, you can meet him at the conference! Other interviews with speakers, including last week's with Geoffrey Grosenbach, will be posted in the interviews section.

Interview with Geoffrey Grosenbach

I thought it would be nice to do a few interviews with some of the speakers we have lined up! For the first one, I turned the tables on Geoffrey Grosenbach, producer of the peepcode screencasts & books, podcaster, interviewer, blogger, developer and trainer. 

MC: Firstly, thank you for taking the time to answer a few questions!

GG: No problem.

MC: Usually, you are the one doing the interview on the Ruby on Rails podcast - do you have any good tips?

GG: I usually find out some side project or other interesting thing and ask someone about that or a current event.

It's easiest to do a podcast interview if the guest has interesting ideas of their own. With Zed Shaw I just put a few questions on the table and he took it away for an interesting interview
Hampton Catlin is also an interesting person to talk to. That interview went over an hour!

I like to hear a podcast where unexpected ideas or questions come up. I remember watching a documentary about a movie director (I can't remember who) and they would re-take a shot until the actor made some small mistake. That was the one that went into the final movie. I'm not trying to make guests make a mistake, but sometimes the conversation winds around ideas or thoughts that I didn't plan to talk about, and that often makes it interesting!

MC: I guess the amount of time you need to spend preparing an interview is fairly small compared with the work involved with preparing your peepcode screencasts?

GG: Indeed.  A podcast is more of a spontaneous, one-shot event. A screencast involves planning and coding, then I do a draft, add a voiceover, and do other post production. So I want my screencasts to be very polished and useful, whereas the podcast has more of a live feel.

Personally, I like it best when I can do an interview in person at a conference or in the offices of a startup. When that can happen, I often find that there's another conversation AFTER the conversation.
And the environment adds to it. I've done short interviews on a subway, in a bar, and even in a van while riding to the airport.

I didn't expect it, but many of my good friends in the Ruby community are people I met when I sought them out for a podcast interview

I gave a short presentation at a business networking conference here in Seattle and advised people to start a podcast even if they don't have any listeners. It's a great way to meet people you admire or just want to have a serious conversation with.

MC: And how do you find people to talk to and pick your interviewees? Do you have a big wish-list, or get suggestions, or find interesting people at events?

GG: I always have a long list of people I want to talk to, and it keeps growing. Sometimes it will be in response to a recent news event. For example, I heard that PennyArcade.com had been rewritten in Rails, so I tracked down Sean Chittenden, the developer who worked on it. Or it was a similar thing when AListApart.com redesigned their site with Rails and I met Dan Benjamin for the first time.
At conferences, interviews often happen spontaneously. Desi McAdam suggested that I talk to her and a few other female developers. That turned out to be a fascinating two-part conversation and has been one of the top downloads.

Lately, I've been travelling less, so I try to call someone on Skype every two weeks.

So there's no overall plan, but I try to keep it current while occasionally talking to people who might be off the radar but are working on projects that I think should be noticed more. For example, I interviewed Christian Neukirchen two years ago about Rack. I'm not going to claim responsibility, but I'm very glad to see that Rails 2.3 is now built on Rack and can take advantage of its features.

MC: Moving on to your other work: As well as the podcast, you produce the peepcode screencasts & PDF books, you do training and you have developed several popular plugins like gruff & calendar_helper... you certainly keep yourself busy!

GG: I often feel that I'm not productive enough, but maybe that's what keeps me motivated to get organized and finish projects.

I think there's also a natural cycle of developing an open source project or plugin, then discovering that it's not that useful (or is complete and doesn't need any more work). Or, I need a feature so I'll add it to a project and keep it going. For example, I implemented bullet graphs in my sparkline gem a few months ago because I needed them for my internal reports at PeepCode.

I've found it helpful to have goals. Yes, this seems obvious, but I went over a month without releasing a podcast and decided to try to release one every other Friday. I've been pretty close to that so far in 2009, and it has actually been less stressful to just put it on the calendar and arrange a conversation every other week.

And of course, PeepCode is my day job. It's a lot of work to start a business but I've refined some parts of my workflow as I discover roadblocks. For example, it previously took me a day or a day and a half to record a voiceover for a screencast. I now do a draft, send it out to be transcribed, then go to a recording studio and do it in about 90 minutes. I think the overall quality is better because I'm working off an edited transcript so I know what I'm going to say. And I don't have to fight with the sound of planes, birds, and cars driving by. The studio I found happens to belong to an independent heavy metal recording label, so it's a fun environment to record in.

MC: Sounds cool :) As you say, you've been working hard on your business by improving processes. You also advocate 'eating your own dog food'. Can you explain what that means to anyone who just started feeling a bit queazy?

GG: In spite of the quantity of open source software available, there's still a value in writing parts of your app from scratch. I try to use existing plugins and gems where possible, but I've been burned lately. Rails changes so fast that the plugins that were previously authoritative are no longer maintained by their authors. So writing one's own plugin makes it easier to know what it does. With a good test suite, you can keep it up to date with changes in Rails.

On the other hand, it's also easy for bugs to occur without really knowing it. So I guess that's one of the values of open source software...many eyes to discover bugs and fix them. But if people aren't reporting bugs or if they never encounter them, the system fails on that account. At one point, I think I was the only person using REST with Rails 1.2 on FastCGI with page caching. I encountered some very weird problems that apparently no one else had experienced. Eventually, they switched the URL syntax to the slash instead of the semicolon. By that time I wasn't using FastCGI anymore, and I'd guess that few other people were either.

But back to the dog food, I tend to write my own when I want a specific feature and it doesn't exist elsewhere or doesn't work the way I want it to. So "eating your own dog food" means that you use the software that you write.

MC: And do you use the same concept for your peepcode work? How do you pick the topics? I notice there are a number of iPhone things in the works - is that something you have a particular interest in, or due to popular demand?

GG: Selecting the next PeepCode topic is one of the most difficult parts of the business, but I'm learning how to do it better. I use the UserVoice suggestion site (http://suggestions.peepcode.com) to get feedback on what people want to hear about. I look at how well other topics have sold.
The Objective-C screencast has been one of my best sellers and has received great reviews, so iPhone-related content will be next.

In addition to finding it personally interesting, iPhone development provides a direct way for people to write applications and profit from them. That's one of the core principles that I started with: Teach skills that will be profitable for the student. My philosophy is that if I teach people concepts that help them run a more profitable business, or increase their hourly rate, or improve on their productivity, that they will be willing to pay for those tutorials. So I want to give people more value that what they paid for.

Some topics have been obvious. Many people were interested in RSpec, but few resources were available. Even now, the first book is yet to be published even though RSpec has been popular for a few years.

Others were topics that I felt I needed to know about, but that weren't quite popular yet. When I did the screencast on Git, very few people bought it. A few months later, around the launch of GitHub and the movement of the Rails source to Git, interest in Git skyrocketed. So it was affirming to place a bet like that and see it pay off.

Now with over 35 screencasts and PDFs, I'm planning a maintenance cycle where I'm going back and updating the older content for the upcoming Rails 3 and newer versions of RSpec and other software.

MC: Well, I think we've just about run out of time already!

GG: thanks for the conversation!

MC: Thanks again for taking the time to chat, and I look forward to seeing you at Rails Underground :)

GG: me, too!

Thanks again to Geoffrey. I hope you enjoyed this interview, I'm working on doing some more, and will be posting them soon! (They should appear in the interviews category)

And we're also using uservoice to chat about proposals or suggestions for talks at the conference - please come and tell us what you think.

Conference Venue

A bit of information about the conference venue:
The Royal National Hotel is situated just round the corner from Russell Square tube, and just a short walk from Oxford Strret.

Discounted rooms are available from £72, and if you book 2 nights and ask nicely, they you can get a free three coupse meal!
Facilities available to guests (not included in the price, though) include wi-fi, a gym and pool, restaurants and a bowling alley!

Of course, there are plenty of other hotels and accomodation in the area to choose from.

Wi-fi wil be available to all delegates during the conference.

View Larger Map