Rails Underground

Joseph Wilk talks about BDD and Cucumber

I had time for a quick chat with Joseph Wilk to talk about Cucumber and BDD!

MC: Thanks very much for taking the time to chat - can you tell us a bit about yourself, and what you do?

JW: I've always been playing around with the internet technologies from a young age, my first jobs were working with designers so I got a lot of early insight into the creative side of building sites. I then went and put myself through a formal MEng in computing, jumped into a J2EE job and then promptly ran away to Python and Ruby.
After playing with Python and Ruby the community and testing culture around Ruby made it my favourite choice. I now spend my time working for a small webshop called eShopworks. I'm currently working on a project building a lite Ruby CMS and I also spend a disproportionate amount of time working on Cucumber.

MC: During that time, I guess you've seen the role of testing and the testing department change quite significantly?

JW: Very much so. I spent some time as the head of testing for a big digital agency dealing with clients like Financial Times and Guinness. I was the head as I was the only member of the test team! Nothing was automated, passing around huge word/excel specification documents was the norm. Little value was seen in testing from the business side. I've also seen testing from the small business side where people did not do any testing and the client was expected to do it for them. Again testing was seen as a cost they could not afford.
I think as the market got more competitive after the .com bubble burst the business folk started to see the advantages they could gain from having a testing strategy.
And the tool set certainly has as come a long way, providing lots of choice for different contexts.

MC: Changes in tools and development methodologies have shifted testing to a much more central role - can you tell us a bit about Cucumber, and how it fits into BDD development?
Haha, you could probably write an entire book on that question... a few sentences will be fine :D

JW: :)
Cucumber is a tool that focuses on filling the communication gap between customers and developers/testers. It allows non-technical people to write/edit/read plain text specifications that are executed as tests. It brings the customers domain language as close as possible to the developer.
As a tool to support BDD Cucumber allows us to work outside-in, focusing on the value to the customer of a feature. Using that value to drive through the layers of the application keeping us focused on delivering the minimal marketable feature.

MC: As a tool that focuses on using a language that the business understands, how does this fit in with the development practice of red/green/refactor? Presumably, you don't have a business owner with you when coding... Where do you draw the line between your cucumber specs and maybe more technical specs that you might write in RSpec?

JW: Very good question.
In Cucumber we dont tend to refer to them as specs, we like to call them scenarios, examples of behaviour.
I think its important to remember that Cucumber is a tool that fits many different usages and contexts. I had an interesting conversation with David Black about writing cucumber instead of specs! There is no one right way.
Cucumber scenarios focus on trying to be as close as possible to how a real user would interact with the system. The customer provides us with a definition of done through these scenarios for a feature.
We start with the same yellow->red->green cycle with Cucumber but its a much bigger cycle. We drop down to the faster red/green/refactor specs when we need to think about implementation details. Cucumber features tend to drive us to the destination but they do not tell us how to get there. Specs help us drive out these implementation details and lower level behaviour. In drawing the line between specs and Features, I often ask myself If I speak to the customer and ask them about this detail what would they say, would they see any value in it.
Since Cucumber features are high level they provide the ability to do some serious refactorings without changes. While the spec levels often requires changes for big refactoring. We wrote lots of Cucumber features for Cucumber before we undertook a big refactor of the internals to give us confidences from the outside of the system everything still worked.
Sorry that was a little long, really interesting question.

MC: Really interesting answer too :) Thanks!
That's great - thanks for those answers, I think we're out of time now:/ Many thanks again for taking the time to chat!

JW: No problem :)

See the interviews category for more.

Rails Business (UK) Meetup

The next Rails Business (UK) Meetup looks like it will take place in London, 22nd July. It's a rather nice way to get together and have lunch with a friendly bunch of RoR developers and consultants, and enthusiasts. Keep an eye out on the meetup site for more details!

Yehuda Katz on Rails 3 and beyond

While I have your attention, I have a few bits of information! :)  I'd like to thank everyone who has submitted a talk proposal for the conference - it's going to be a real challenge to pare down the selection to the ones that we can fit in.  I'll be trying to sort this out over the next week or two, so please bear with me if you are waiting!
A couple of people have asked me very nicely if it is too late to submit a proposal. If you want to try, please do, spots might become available depending on speaker circumstances, etc.

But, enough of that for now, here is the latest chat with one of our conference speakers: Yehuda Katz, member of the core teams for Rails and jQuery, lead developer of the Merb project, core contributor to DataMapper contributor to Rubinius and Johnson, creator of Thor, Moneta.....:

MC: Firstly, Many thanks for taking the time to chat! I know you're very busy. Could you tell us a bit about yourself, and what you are spending your time on at the moment? 

YK: Sure. My main focus at the moment is continuing work on Rails 3. At the moment, that involves significant refactoring of ActionController and ActionView. We've made significant progress, and are already seeing architectural benefits from the improvements. In my spare time, I'm currently working on Moneta (a key/value store abstraction) and improving Rubygems (with better gem resolution, lower start-up costs, and bundling). I also have been sinking some time into JRuby, which is proving to be a very stable, fast and reasonably agile alternative Ruby implementation.

MC: Rails 3 is generating a lot of excitement. What changes do you think will make the biggest difference to developers?

YK: For power users and plugin developers, the internals of Rails have become significantly improved, and it's now possible to make many more kinds of changes to Rails without invasive monkey-patching or real patching. This includes things like overriding the controller's rendering system, swapping out template backends, and having configuration options scoped to an application instance rather than globally.
For application developers, we will be able to leverage those architectural improvements to create interesting features. This includes improving engines, bringing ActionMailer in line with ActionController, a new Queue system baked into Rails, more flexible and powerful routing, and easier integration with the world of Rack components.

MC: So, there are many changes that will allow functionality and applications to be plug-able. Do you think the focus of rails development will shift from the core to the efforts of the wider community?

YK: There will be two parallel results. First, the Rails core will focus more effort on making sure that the core of Rails both remains an excellent set of defaults for users building web apps *and* becomes a viable backbone for other kinds of interesting work. This requires intense work in the core of Rails itself, and will need to continue even after Rails 3 is shipped as we move forward. Second, I personally anticipate more community activity around leveraging those new capabilities. So it's not so much a focus shift from Rails to the community as it is a renaissance of efforts on both fronts.

MC: I was going to ask specifically about what is in store for rails after 3.0... There seems to be a hint there that you may be looking at rails in a broader context than just web apps?

YK: Rails is certainly going to become potentially more useful in the context of all HTTP applications (not just HTML), but I don't see it moving outside the realm of HTTP at all. The great thing about Ruby is that it's very easy to make code interoperate; for instance, Sinatra is excellent for taking an existing Ruby project and exposing it to the web. I think it makes sense for Ruby projects to be as good as possible in their own spaces without trying to become too generic.

MC: So have you got any other clues about the sort of changes that might be in store after rails 3? How is the development timeline decided upon, and what sort of timescales into the future does the core team look into?

YK: It's hard to say at this point, but what should be clear is that Rails 3 is just the first fruits of the reinvigorated work on the core of Rails. We have four very exciting Google Summer of Code projects, some of which might make it into a 3.x version of Rails (although I hope they all make it into Rails 3). My personal expectation is that Rails 3.x will be driven, as usual, by the needs of the community, which will now be somewhat focused around the new integration points we make available starting with Rails 3.
In terms of timeline, we're trying to release as soon as possible, without waiting for a mythical perfect release, but we definitely need to get the integration points stable to deliver on the promise of a stable plugin API.

MC: Thanks, I'm really looking forward to trying out the new features... One thing I'm really excited about is the stuff you talked about in the 'Russian Doll' talk... I've only managed to see the slides so far, though. This idea of plug-able applications looks like it could bring some huge benefits to developers.

YK: The Russian Doll stuff is really interesting, because the work that needs to go into Rails is really separate from the end feature we want to enable. In Rails, we need to add stuff like allowing multiple Rails applications in one process (via an application object), improve the system for pulling out templates off the file system or other locations, improved bootloader process, and a more robust and powerful router. Those features are pretty much unrelated to the idea of mountable applications, but will enable interested members of the Rails Core team and members of the community to build a working, standard system on top.

MC: You had some slides in that talk referencing Django... I think we have just enough time for one last question...What do you think rails can learn from other app frameworks like Django, and do you think the rails community is engaged enough with the wider community & 'the enterprise'? (I'm thinking of the message of Bob Martin's RailsConf keynote)

YK: The most interesting thing in Django is their embrace of multiple applications, as well as their built-in administrative "application". On the other hand, their grudging, slow support of WSGI (the inspiration for Ruby's Rack) is something Rails must be sure not to do. Thankfully, Rails' participation in the larger Rack community has been inspiring and transformative.
In terms of the enterprise, I certainly think this is something we need to do, but it will likely need to be driven by companies with some skin in the game. Bootstrapping that process is difficult when so many community members are refugees from that world, but I definitely anticipate efforts to engage the enterprise in a discussion about the benefits of Ruby coming from various avenues. I only hope that those efforts really sell the power of Ruby, and try to avoid encouraging people to write Java or .Net with Ruby syntax. There's much to be gained from fully embracing Ruby as a language, with its idioms and libraries.

MC: We're out of time! That was great - lots of food for thought there Thanks very much for taking time out to chat!

YK: No problem. It was great chatting with you.

There are a few more interviews planned, and you can find previous talks with Geoffrey Grosenbach, Maik Schmidt, and Dr Nic in the interviews section.

Handy resources for people new to Rails

I have a couple of updates planned for this week, stay tuned! In the mean time, I've been speaking to a bunch of people fairly new to rails, so I thought I'd point out a couple of great places to visit if you are new to rails and are looking for some good places to start. (There are, of course, plenty more, but you have to draw the line somewhere) :-

Great Pod/Screencasts

1. Railscasts. Ryan Bates gives realy excellent screencasts covering many rails topics. These really are very good :) Eifion Bedford has converted many of these into a text version.
2. Rails Envy. A useful round-up of weekly ruby and rails news, and you can find lots of good links in the show notes.
3. Ruby on Rails Podcast. Great interviews and chats with ruby luminaries and entrepreneurs.
4. Rubyology. Code Monkey, Chris Matthieu has been hosting this podcast for a long while now, and there have recently been some great round table discussions worth listening to too.

Handy Information Resources

1. RailsGuides - great resource for learning rails.
2. Stack Overflow - helpful programming Q&A community site.
3. Rails Tips, "One man, feverishly posting everything he learns."
4. Ruby Inside and Rails Inside - all the ruby and rails news that's fit to print.

Community Links

1. If you live or work around London, the London Ruby User Group has regular evening events and lots of interesting chat. Further afield in the UK is the North West RUG and the Scottish RUG. [Update: And Leeds Ruby Thing!] Further still, try looking on the meetup site.
2. Rails Activists - The 'official' group, working to empower rails users, and working on projects to improve the rails platform.
3. Railsbridge Another community of rails developers hoping to strengthen and broaden the rails community through various projects and activities. 
4. I started compiling a list of other regional conferences that people may be interested in, but soon found a great list.
5. Rails on IRC
6. The Ruby Forum also containing several others), and the Rails Forum are both good places to chat & ask questions.

There has been a lot of debate over the past few weeks about the Rails community, how to make it more inclusive and welcoming, and how people can help out.
Railsbridge just got going a few days ago but is a great example of how many people there are within the rails community with a great enthusiasm to help. Already in the works are mentoring programs, kids educational activities, courseware and workshops.

I'm hoping to find out more about these sorts of efforts, and include activities during the conference that will help people find ways to get involved. If you have any suggestions, please .
Any glaring omissions? Leave a comment! [Update:

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.

Tutorial / Workshop

I'd really like to organise a tutorial / workshop for the day before or after the conference. I've posted a few thoughts about it on the google groups forum, and I'd really like to hear your ideas.
Would you rather it take place before or after the conference? What format or topic would you be interested in? Would you be happy to make a donation to charity, or do you want it to be free?
If you are interested in attending, or if you have any thoughts or suggestions, please let me know, or see what other people think on the forum.

Speaker Topics: Your Ideas

Thanks so much for the speaker proposals that have already been submitted!

I've updated the Speaker RFP page with a few more details, based on some of the questions I've received.

I've also set up a special discussion forum, where you can let us know what you would like like to hear, and comment on other ideas.

You can vote up the topics you like and add comments, questions or suggestions. If there is a topic that interests you, but it is not listed, please add it! 

Hopefully this will be a great place for speakers to get inspiration and feedback, and delegates to suggest topics that they want to hear more about. I hope you like it!

Interesting browser stats :)

Lots of interest since the site went public, producing some wonderful log stats:

2.8% IE, and dominated by MacOs and Linux!