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.

List of speakers

The full list of speakers for Rails Underground is now available, and its fantastic!
It's very exciting to have such an excellent line-up of awesome talks! The full details on each talk and the schedule will be coming out over the next 2 or 3 days, as soon as I can type them up, but I couldn't wait any longer to get the line-up out there...

It has taken quite a while to get everything sorted out - we needed to sort out some extra time at the venue and jiggle things around a bit in order to fit in as many of the brilliant talk submissions as possible. Thank you to all the people who made the job so much harder by submitting far too many great talks to fit them all in! Also, the masses of people on the forum who provided ideas and suggestions and gave feedback on the talks they would most like to see. Many thanks!

As well as the scheduled talks, we're planning a session of lightning talks in the evening, where anyone can put their name down to give an impromptu, short (say, 10 minute) talk on any subject they like... We'll also have an 'open mic' at lunch times for people to make short announcements or introductions. For example, job opportunities, a quick introduction for a company or new product, or just to say 'Hi' and show your face.

We also have a slot available for a workshop for the day before the conference, details are TBC, so if you have any ideas, shout out!

Charlie Nutter on JRuby

It's taking a while to go through all the excellent talk proposals and try to fit in as many as possible into the schedule. In the mean time, I had a quick chat with Charlie Nutter, who will be speaking at the conference. Charlie is co-lead on the JRuby project. [The JRuby homepage is undergoing a revamp over the next week or so. You can find other information on the wiki or the codehaus site.]

MC: Firstly, can you tell us a bit about yourself and your work?

CN: Well, about 5 years ago I went to my first Ruby conference, and liked the language so much I looked up JRuby. When I found that an old friend of mine, Tom Enebo, was leading the project, I started to contribute. At the time I was a "Java EE Architect" but in early 2006 Tom and I and other JRuby community members really started trying to make JRuby solid. Later that year Tom and I joined Sun Microsystems, and I have been working on JRuby ever since. Over the past couple years, I've also tried to be an advocate for JVM languages and Java/JVM improvements that would make language development easier. So I'm a JRuby co-lead on one hand and a JVM languages advocate on the other. It keeps me pretty busy.

MC: I didn't realise JRuby has been going for such a long time! I know its just marked 3 years or running rails, and the 1.3 release is imminent... can you tell us the latest JRuby news?

CN: Latest is subjective; we've had thousands of commits and hundreds of bugs fixed in just the past few months. A few months ago, we released JRuby 1.2, which included more bug fixes and improvements than the previous 3 releases combined. It was also the first JRuby release that started to be convincingly faster at running Rails than "Matz's Ruby Implementation" (MRI). A number of long-standing bugs were fixed, and both memory and performance were a lot better than the previous release.
This week, we've released hopefully the final RC for JRuby 1.3.0, which is mostly a bugfix release. JRuby 1.3.0RC1 was rushed out the door for RailsConf largely to release fixes for Google's AppEngine for Java, which works fine with JRuby. Since RC1, we've had enough additional fixes that it probably was more of a beta, but for RC2 we've actually branched and will release 1.3.0 final next week.
Perhaps the most interesting recent news is that JRuby adoption seems to be accelerating very quickly now. We're seeing job posts, big production site announcements, and I know of at least two announcements coming next week that will further boost JRuby's profile. And we're not standing still...this summer's work on JRuby 1.4 will have a new focus on improving performance (via an improved compiler and upcoming Java 7 features) and improving Java integration (bringing Ruby and Java object models closer together). Expect to hear more about that soon.

MC: Do you find there is a common use for JRuby? Why do developers typically decide to use it?

CN: The majority of JRuby adoption is from Java-based organizations that want to start using Ruby or Rails internally. It's generally too great a political struggle to get MRI introduced into any large existing production setup, and if JRuby supports all the Ruby libraries and code you want to run, you don't have to fight that battle. We hear from banks, telecom, financials, governments, and others that are running sites on JRuby, and every conference we go to we learn about another half-dozen we didn't know about before.
There's also a growing number of folks using JRuby to get better X, where X may be performance, available libraries, memory utilization, multi-core scaling, and so on. While we've always focused on being a compatible Ruby implementation first, we've also tried to give people solid performance, real parallel threads, and access to everything the JVM has to offer. Many people are starting to recognize that and move to JRuby.

MC: "Being a compatible Ruby implementation" must be a bit of a challenge - defining what Ruby is can be quite hard - If you define it as "Whatever Matz says it is", it can still depend on the point release and sometimes the patch level... Can you tell us a bit about RubySpec and how it fits in with your work?

CN: Ruby is, as you probably know, a language without a formal specification. That means we have generally had to cobble together a test kit over the years in order to know whether we're "compatible". Early on, that meant pulling in Rubicon, a set of test cases Dave Thomas wrote when working on the Pickaxe books. Over the years, we've also pulled in MRI's test suite (which is surprisingly small), a test suite called "ruby_test" written by Daniel Berger, a small suite called "BFTS" written by Ryan Davis and Eric Hodel, and finally RubySpec, which I'll come back to. We've also accumulated a very large corpus of our own test cases. JRuby now runs far more tests than any other Ruby implementation, even if you assume there's a lot of duplication.
RubySpec is a project started by the Rubinius team a couple years ago. It's basically an rspec-like set of acceptance tests/specs (I won't debate nomenclature) for all of the Ruby language, core classes, and standard library. It's not complete, but it is of a comparable size to all the other suites we run against JRuby, and much cleaner. Because RubySpec started somewhat after JRuby had surmounted the biggest compatibility hurdles (like running Rails), it has been mostly an additional tool for us to keep improving compatibility. But we fully support and appreciate RubySpec and try to contribute new tests and specs as often as possible.

MC: Another metric you spend a lot of time on is performance and benchmarking. There are many different comparisons of various Ruby implementations (some of which are still 'works in progress'). How would you say JRuby performs compared to other implementations?

CN: We haven't spent as much time on performance as a lot of implementations (especially some newer ones) but I'd say JRuby is at least on par with Ruby 1.9 for running Rails and faster for many smaller tasks. Part of the problem of measuring performance is that it varies so much from application to application. We still get reports of people with Rails apps significantly slower than on MRI while at the same time others report their apps are many times faster. There's no reliable benchmarking suite available for Ruby yet, so we usually have to guess at what the problem might be.
However I will say this: we consider poor performance in JRuby to be a bug...not because we're cocky, but because in almost every case of poor performance it has been something we were doing wrong. So if we can isolate the problem down to a specific piece of code or a specific method, we can usually fix it and often exceed Ruby 1.9 performance at the same time.
Another complex aspect of performance measurement is that most applications depend on code not measured by the microbenchmarks people usually publish. For example, JRuby has scored better on Antonio Cangiano's "shootout" for well over a year, and yet just recently started running Rails faster. Why? Because Rails is not limited by Ruby execution performance as much as by the performance of the core classes. It's easy to get Ruby code to run fast on a given impl, especially early on. But getting all the core classes to perform better is a very slow process, and any one class or method can cripple an entire application.

MC: One last question! If anyone out there wants to help contribute to JRuby, what would you recommend?

CN: We love contributors, and so does our community! The quickest way to get started would be to visit jruby.org, which has links to downloads, howtos, mailing lists, IRC, bug trackers, and articles about JRuby. Installing JRuby is simple: provided you have a Java version installed (1.5 or higher), you just unpack JRuby and it's ready to go. And if you want to help fix bugs, or find a bug you'd like to report, it's easy to check out JRuby from github and build it. All this is detailed in articles on jruby.org, or you can contact us directly via email, mailing lists, or IRC.

MC: Brilliant! Thanks very much for taking time out to chat, it was a real pleasure; and I'll be looking out for those announcements next week!

CN: excellent, thank you!

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.

Talking to Maik Schmidt: Enterprise Rails

Time for another interview with one of our speakers: Developer and author Maik Schmidt. For more, see the Interviews section. If you are interested in speaking yourself, please check out the speaker applications page for more details.

MC: First thing: Thanks very much for taking the time to chat!

MS: You're very welcome!

MC: Can you tell us a bit about yourself, and your experiences with ruby?

MS: I am 36 years old and I live in the west of Germany.
I've worked as a software developer for more than 16 years now and I've mainly worked for big companies, that is I have created lots of big enterprise applications using Java and C++. In 2000 I have bought the first edition of the Pickaxe and I've liked Ruby from the beginning. Since then I've started to sneak it into as many projects as I could and in the last years I have written more code for the Ruby platform than for the Java platform, for example.
I have used Ruby not only for creating web applications with Rails but also for standalone enterprise applications.

MC: You've also written two books on Ruby and Rails in the Enterprise, right? And I think you have a third one on the way?

MS: That's right. I am the author of "Enterprise Integration with Ruby" and "Enterprise Recipes with Ruby and Rails" (published by The Pragmatic Bookshelf). Both titles contain the essence of all the things I have learned during the last years and I've written them for people like me, that is for software developers that want use Ruby (and Rails) in typical enterprise environments. For example, they explain how to process large XML documents effectively or how to participate in asynchronous messaging systems.
A third one is on the way and I cannot say too much about it (contract signing is still in process), but it will be no Ruby book. After writing two Ruby books I wanted to do something completely different. Not because I do not like Ruby any longer (quite the opposite), but because I wanted to learn something new.

MC: Intriguing... OK, so let's talk about Rails and the Enterprise: When you talk about developing in the Enterprise, what do you mean? What would you say defines an enterprise environment? 

MS: The best definition I have is from Martin Fowler: "Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data."
So, first of all, enterprise applications usually have to process large amounts of data, which can be a problem by itself. But for me the biggest challenges have always been on the organisational side, that is clarifying requirements with many different departments and integrating with countless existing systems, servers, and databases. Ruby is not a perfect candidate when it comes to processing large amounts of data, because the current platforms are all relatively slow compared to other platforms. But Ruby really shines when you have to glue together existing applications or when you have to create small domain specific languages to describe fairly complicated business processes in the most elegant way. And when it comes to developing web applications that use your existing back-end infrastructure Rails is a powerful ally. 

MC: And presumably dealing with a heterogeneous system is a factor too - lots of different file systems, databases, interfaces, environments, etc.? 

MS: Absolutely! I've often found surprisingly simple solutions to seemingly complicated integration problems, because Ruby really is sufficiently platform-independent. There are still some minor quirks on the Windows platform, but when you live in the Unix world everything is really fine.
Hiding most legacy stuff - no matter how heterogeneous your environment is - can often be solved by simply creating new services (preferably REST services, of course). As the saying goes: "There's no problem that cannot be solved by introducing another layer of indirection"
The same is true for databases. It's really surprising how many problems can be solved with a solution as simple as ActiveRecord (its API is simple, that is).

MC: So, I don't know if you saw the Core Team Q&A at RailsConf last week... One of the questions was "Will Rails 3.0 be Enterprise-ready?" Koz said "No," I think it was Jeremy Kemper that said "It already is," and Yehuda said it was a contentious issue... Having already had a lot of experience of using Rails within an enterprise environment, how would you answer the question?

MS: It heavily depends on the task you have to solve. In most regards Ruby is Enterprise-ready and I have proved it several times by deploying applications in really big enterprise environments. Currently, I am working on a product for Vodafone (http://widget.vodafone.com) that is already available in several countries.
But there are still many areas that need improvement before Ruby and Rails are enterprise-ready in general. For example, Ruby needs a better runtime environment, but I am fairly sure that JRuby will fill this gap shortly. Rails needs much better support for internationalisation (this has been the biggest problem in my current project) and a slightly better release management.

MC: Yes, I guess JRuby goes a long way to giving Rails projects an entry point into the usually tightly locked-down and subject-to-slow-approval-processes application environments within the enterprise... Has the recent rails i18n work helped?

MS: We started developing the application when i18n has not been a part of Rails (before the 2.0 release), so we have used good old gettext. We could integrate gettext and its tools into our whole development process without any problems. Tool support is a very critical issue when you develop large applications in an international environments. Right now we support English (UK, Ireland, South Africa), German, Dutch, Greek, Italian, Spanish, and Portuguese locales and all translations are provided by employees of local Vodafone companies. Of course, none of the translators is a software developer and so they need intuitive tools for writing the translations. gettext is absolutely mature and we never had any problems with it.
Of course, rails-gettext was not perfect (for example, it's not possible to translate ActiveRecord's validation messages as flexible as we need to), but we could solve nearly all our problems with monkey patching. When we started to migrate our application to a more recent Rails version, of course, we had a look at its new i18n features. Unfortunately, they did not solve the problems we already had with gettext and it even made some things worse, especially on the organisational side of things. As I said before: tool support is critical when you have to support multiple locales.

MC: That's food for thought... and gosh, I'm taking up all your evening! Thanks very much for the chat I look forward to continuing it at the conference!

MS: Thank you! I am looking forward to seeing you at 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.

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!

Join In

In case you missed it in the big announcement, we are still looking for speakers, and are keen to hear your ideas.

If you have a great idea for a talk, the Request for Proposals page has more information for speakers.

However, if you don't want to talk yourself, we would still like to hear from you: Please tell us what topics interest you the most. You can e-mail, leave a comment, or better still, join our google group and start a discussion.

You can help shape the conference too. There are lots of other topics coming up soon - I'll be adding more info when I draw breath.

Subscribe to Rails Underground

Email:

Visit this group