eRubyCon - Bruce Tate
From eRubyCon in Columbus, OH.
Interviewed by Robert Stevenson
Geoffrey Grosenbach: It’s the “Ruby on Rails Podcast”. I’m Geoffrey Grosenbach. It’s been about two months since the last episode of the Rails Podcast. I went on vacation, enjoyed the summer, been working hard on PeepCode new screencasts, on RSpec, and Ajax with Prototype, but ready to go back strong with the Rails Podcast, got some great interviews planned for the fall. I’ll be at RailsConf in Berlin in a couple of weeks, but for today, faithful reporter Robert Stevenson was at eRubyCon in Columbus, Ohio and spoke with Bruce Tate.
This is probably a good opportunity to mention that Bruce Tate, Ezra Zygmuntowicz and I contributed to “Deploying Rails Applications”, a new book from The Pragmatic Programmers, now available as a Beta PDF book, in print later this fall.
Robert Stevenson: Hey, this is Rob Stevenson from the Columbus Ruby Brigade. I’m here at eRubyCon in Columbus, Ohio, and with me today is Bruce Tate, who’s giving talks on ActiveRecord and collaboration. It’s great to have you here.
Bruce Tate: It’s great to be here.
Robert: You recently, late last year, switched jobs from being an independent to being part of a company. I wonder if you could tell us about your new venture.
Bruce: Yeah, I started a bunch of years ago, probably 15 or 16 years ago at IBM, one of the biggest companies, and I gradually got smaller until I got down to zero, and now I guess I’m building back up again, you know. [smiles] Two years from now, I’ll be in Microsoft or wherever. But the new company is WellGood LLC, and we are building a charity donations portal called “Changing the Present” and it’s tremendously exciting for me to be using technology that I love, working with people that I love, and actually hopefully change the world at the same time.
Robert: So tell us about “Changing the Present”.
Bruce: This is an on-line donations marketplace, and there are a couple of things that are unique about it. First, the technology in the non-profit sector is about 20 years old. There’s really some horrible technology out there, and it’s a shame, because that really impacts how much of the money that you would donate would actually make it through to a non-profit. If you can be more efficient, then more money will get where it needs to go, so we want to make things more efficient.
Second, we would like to change the social norms for the way that people think about giving. My Mom got sick: she actually broke a bone in her neck a couple of months ago. She’s OK, but we got a lot of flowers and the first couple of sets of flowers were great, and then the next 27 made it to the trash [smiles] and that’s tremendously wasteful.
Or, if you think about conferences, most of the gifts that are given wind up in the trash. So if you can harness, not all the gift revenue, but just the stuff that makes it in the trash, you can really change the world. So, we would like people, instead of giving that seventh pen and pencil set, or another pair of fuzzy slippers – I know you’ve got four or five pink ones. [laughs]
Robert: Shh, don’t tell them.
Bruce: If you can just harness that and instead give an hour of a cancer researcher’s time, preserve an acre of the rain forest, make a blind person see, which it turns out you can do with cataract surgery for about $30, now instead of another pair of fuzzy slippers, or another backpack for a conference, I’m making somebody see. And that’s a pretty exciting thing for us.
Robert: Now you have written nine books, per your bio, and the majority of these books have been Java books.
Bruce: A good number, there’s even some OS2 back there if you go far enough.
Robert: In the Amazon way back machine.
Now, you’re well-known in the Java community for continually offering up the red pill, and showing the community that Java’s not the end-all be-all, and so did you come into WellGood, saying: “Let’s do it in Ruby” or was that a decision that was already made as far as creating “Changing the Present” as a Ruby on Rails application?
Bruce: I basically came into the WellGood situation with a start-up that needed what a lot of start-ups need. We needed to be extraordinarily efficient and we knew that since we were building something that nobody had built before, and since we had an idea that we thought was compelling, of course the things in the front of your mind are: “Can I build this before I run out of money?” and: “Can I build something compelling? And if I do build something compelling, can somebody else just build the same thing faster and take my idea from me?”
So, I needed to be efficient and I needed to be able to grow for the long term. I was building a big fat database in order to baby-sit that with a Web-based UI, and Ruby on Rails was the right tool for the job. I have nothing against Java; I think it’s a fine language for what it was intended to build, and that’s primarily more middleware and basically systems. It’s based on C which is a systems language. But for 10 years, we’ve been building applications in a systems language, and I don’t think that’s a good idea.
Robert: What did Ruby on Rails do as far as the development, and how did that change the way that you obviously used to build applications in Java?
Bruce: I think that things are changing rapidly and on a whole lot of different levels. The first level is the idea of offshoring and outsourcing. When I started developing applications and when I started consulting, I would always be very conservative with my technology choices, and the reason is that there wasn’t a reason not to be. You just wanted to avoid risk and you were willing to trade a little bit of time to do it.
With offshoring and just outsourcing in general, there are people that can and will take your job if you let them. And I think that the way to beat offshoring is to establish better communication with the customer. The only way that you can do that is to have a rapid feedback loop between the time that you start talking about a new feature and the time where you put something in front of your customer. Ruby on Rails lets us do that. We can have a demo once a week and accumulate a couple of hours’ worth of changes – our demos take a long time, because we’ve done something real in the span of a week. And I can’t do that with any lower level language. So we’re always looking for leverage points. Technology is one.
The other thing that Rails lets me do, is since I can do more work with each line of code, I wind up working with fewer developers, and since I wind up working with developers on the top of the food chain, I wind up working with still smaller teams. So we’re literally doing the work of two or three that other consultancies were projecting as a fifteen person job, and we’re coming in at half the time-line and that’s an exciting thing.
Robert: Well, let’s talk about teams and the enterprise. You know at Enterprise Ruby everyone is saying the same thing as far as whenever they were able to bring in a Rails application and compete against more traditional web applications written in Java and C#.NET. I’ve been in the enterprise for a long time, and it just isn’t that easy to go to your manager and say: “You know what? Struts 1.1, that we’ve been using now for God knows how long, I’d really like this new project to be in Ruby on Rails because of a, b, c.” How do you sneak Ruby in Rails into an enterprise? (I hate the word “sneak” that we always have to say, because it’s something that definitely should come through the front door and not the back door.) How do you get Ruby on Rails into an enterprise?
Bruce Tate: Well, I’m actually lucky that, as an independent for so long, I’ve been able to make the conversation not about technology, but about the business. If you tell me that this particular project is going to cost $X in Java, and I tell you that it’ll cost half that much with Ruby on Rails, or you have to recruit half the programmers, or you can finish two to three times as fast, that’s a compelling business reason.
When you’re talking about those reasons, then it all becomes a question of how much risk you are willing to put up with for that particular reward. If, for example, as the risk profile for Ruby goes down, as we blast past the million download number and start approaching two million, well now you’re talking about having as many downloads as the flagship Java frameworks. So, it’s a little bit less of a concern.
The other thing that I do is, I talk about the team dynamics. When you can build smaller teams, then you can build much more effective teams, because adding to a team adds exponentially to the cost of developing software. You increase the communication channels, you increase the interface boundaries, you multiply the opportunities for bugs. So smaller teams build better software. We’ve known that for a very long time.
Robert: How are you able to… We talked about this earlier, that I’m running a team where I’m at now, that is based basically all on offshore developers. The team that I’m on does not have a full-time employee on the team as far as a developer. How do you see this small team working with places, enterprises, big enterprises that have thrown their interest towards throwing the money at offshore developers, as a way… because these people are smart and they work for a lot less.
Bruce: I think that you’ve got to make a big distinction between a distributed team and an offshore team. Now I think the model for offshoring is, curiously, bringing some development shops closer to a waterfall development process, that’s a process where specifications are up front, everything rolls into development, everything rolls into unit tests, system tests and then out the door.
If you think about it, you need more specification work done up front of an offshore project. You need rigorous unit and rigorous integration and acceptance testing on the back-end of an offshore project. Now, try to tell me the difference between that and waterfall. You really can’t. Right?
So I think that, if you’re thinking about Ruby on Rails, it really gives you a chance to break that waterfall cycle. You can actually use Ruby on Rails to build smaller teams, and to build with less, and build it here, where you can have that close communication with the customer, where you can shorten the feedback loop, and you can get code in front of the customer at regular intervals.
Now, I’m a little bit of a radical, in that I believe that you can do this with a distributed team. I have developers in New York, in Columbus, in Calgary, that we’ve used to build this application. Curiously, the guy in Calgary is Clinton Begin, who is the author of the Java Framework called iBATIS. Clinton is a technology agnostic: if he believes that Rails is the right technology for a problem, then he’s going to work with it.
Now, I know that we are paying a penalty by having a distributed team. We’re not able to prepare a program as seamlessly, but if I can go get the best developers in the world, then I think that we could overcome any disadvantages that we have to proximity. So I always build a very careful distinction between a distributed team and an offshore team. The traditional offshoring model is much closer to a waterfall and I think that the answer to the question: “How do I do that with Rails?” is that you don’t.
Robert: Let’s go back to “Changing the Present” and charity in general. Recently the Ruby community has really stepped up, and especially with Chad Fowler; at RailsConf they put down the challenge to raise money for charity. This was started with Dave Thomas and Mike Clark who started the guidebooks that would allow people to – for some amount of money donated to charity – come to a pre-conference tutorial on Ruby on Rails.
What is it about the Ruby community that fosters this kind of attitude? We’re not saying that Java people aren’t giving and so forth, but it really is the Ruby community itself that has stepped up, and every conference
- even eRubyCon right here - use “Changing the Present” to do a charity drive. Now it seems like the norm for Ruby on Rails conferences.
Bruce: I think it’s a fantastic movement, and isn’t it interesting that it’s the same people who have given so much time and so much energy to establishing the Rails framework in the first place – people like Dave Thomas, Mike Clark, Chad Fowler. They’ve sunk countless hours into establishing Ruby on Rails as a viable open source platform, with co-contributions, with technical writing, which you’ve got to do out of love: you’re never going to make a lot of money doing technical writing.
But I think it’s important that these people are looking, not just for ways to give, but ways to give with leverage. The same way that I talk about coding with leverage, by using smaller teams and better technologies, we have people with big names and they are using those names to attract attention and to provoke action on noble causes.
One of the things I’m very excited about doing, is actually building a platform that we can use for things like those workshop registrations, and actually the e-commerce engine, to drive the giving through that process, and to do the record-keeping, and frankly to help people promote a noble cause.
Robert: You gave a talk yesterday at eRubyCon here, called “Stretching ActiveRecord”. Can you go into your talk and give an idea of some of the things you talked about?
Bruce: Yes, that was an interesting talk to give, because I basically walked through a lot of the mistakes that I’ve made, and some of the solutions to those mistakes in two years as really a pretty green Ruby developer.
I talked about the object-relational mappers that Java has, and all the inheritance modeling that you can do on the Java side, and trying to shoehorn my Java thought process into the Rails model. That took me to a sad place [smiling] and we don’t want to be in a sad place, we want to go to the happy place. So I learned to stretch the way that I think about various problems, like, for example, instead of trying to build a whole inheritance model, sometimes I’ll use polymorphic associations.
So instead of saying: “OK, everything on my website is content,” well, if I were to follow the Rails inheritance model, then everything would be crammed into a content table, and all the sub-classes of that would be with different properties. That’s clearly not a manageable solution. One of the things that I can do, though, is break out a small content descriptor that I can then add to a class with polymorphic associations.
The other thing that I can do is realize that I’m not coding in Java any more, I’m coding in Ruby. And I can make… Instead of having one big fat content column, I can have small pieces of content like non-profits, and causes, and gifts on my side and I can make them all quack in water. I can use duck typing, so as long as I add the common behaviors in a module, and just name and declare the fields in a similar way, then these things will behave as if they were one big inheritance tree, and that works for me pretty well.
I also talked about some of the things that I learned earlier on, such as dealing with very large trees. There’s a niche design pattern that I used, that I haven’t codified yet as an Access plug-in, but it’s using materialized address. So instead of doing a nested set, which is great for dealing with categories and things that don’t change… (The problem with a nested set is that when categories do change you have to re-number the whole set.) With the concept of a materialized address, well, I can label something, like I label the Internet 1.4, 1.7, 1.16, which is just a materialized list of identifiers, and I can express a tree that way, with some pretty surprising results.
Robert Stevenson: Let’s get into the Java side, that most people would recognize your name with, and the excitement that has fairly recently come around with JRuby. You have a lot of Ruby luminaries getting very excited because this seems like a great open door into the enterprise, something that can be easily brought in, whereas maybe something in Rails would be a little more difficult to do. How do you see JRuby helping Ruby and Rails breaking into the enterprise?
Bruce: It’s very interesting that when you see something like JRuby as it’s under development, you’ve got a use case in your mind, maybe a couple of use cases. In “From Java to Ruby” I wrote about some things that look absolutely fascinating to me, like using Metaware and Java like rules engines, and expressing scripts in a scripting language like Ruby. So, wouldn’t it be great if you could put real, natural domain-specific languages into Java rules engines to make some business rules that look like business rules? [laughs]
One of the most exciting experiences of moving to Ruby on Rails, was putting some ActiveRecord code and actually some Access state machine code in front of business users with no programming background and doing code reviews with people without a coding background. And actually finding bugs and getting worked on that way was tremendously exciting. So to look at that in the context of a business rule, looked like it would be very interesting.
Now, that was about a year ago that I wrote “From Java to Ruby” and now, everything has changed. JRuby is out, and the first commercial application, or broadly deployed commercial application, with JRuby is using Rails with a Java Swing client.
Bruce: Now that just sounds like complete science fiction to me, but there it is. You have probably what has a very real possibility of becoming the de facto tool for managing agile projects, running [smiling] as a Java front-end to a Rails back-end on JRuby with a little bit of Ajax mixed in and a lot of ingenuity.
So I guess that’s a long-winded answer to say: “I have no earthly idea of what’s going to happen.” I just know that JRuby is going to make it possible to do natural scripting things in a scripting language.
If you think about it, a whole lot of what we do is scripting. Integration, writing unit tests: that’s a natural scripting exercise. Building WET web pages, we know that JSPs are badly flawed and broken. We know that the Ruby pages are working very well with Rails, and we’re actually seeing some new languages that express HTML better than HTML does itself. And that’s exciting in its own right. I think that those things have a natural home on JRuby, but we just have no idea where it’s going to go. We’ll just have to watch this crazy ballet play out before us and just enjoy the ride.
Robert: Do you think the excitement for JRuby comes more from the Ruby side or more from the Java side? It seems that as far as the Ruby side, we have Rails which allows you to build your web applications, and the need to tie into a Java background seems only something that’s needed in the enterprise, which Rails has not really embraced, because the majority of people that write Rails applications are not in the enterprise and don’t have any need for that.
Bruce: I don’t know, I think that, gosh, what if I’m a Rails aficionado and I want to build this Rails application, only this database is Icarus? [laughs] There’s a JDBC driver out there; there’s a JDBC driver for everything, and wouldn’t it be great to use that JDBC driver and get some of the inherent enterprise integration?
Wouldn’t it be nice to put Ruby integration code right around some robust messaging applications? It would be nice to use some of the Java e-commerce and security implementations, so there are a lot of APIs that Ruby developers could definitely use, but I think that I tend to agree with you for the most part that this could really give new life to the Java platform, and when we look at Java 30 years from now, we’re either going to say it’s effectively dead – dead like COBOL, not like Elvis, right?
Bruce:... or that the legacy of Java is the Java platform, the JVM. And I think that that is an argument that you would have thought was dead three years ago or five years ago. But now it’s very much alive with JRuby and PEP, other languages, also additional languages that are more dynamic, that are targeting the JVM.
Robert: Well, the site is www.changingthepresent.org and you can follow Bruce on his blog at www.blog.rapidred.com, and I’d like to thank Bruce very much for sitting down with me for an interview.
Bruce: Thank you very much for having me.