podcasts

S01E05: José Valim

14 Jan 2011

José Valim talks to us about Rails 3, Crafting Rails Applications and the cool new projects he is working on. Danish: Today we have José Valim with us, one of the Rails core team members. Will you introduce yourself?

José: Hi, I am José Valim, as you said I am a Rails core team member, and I work at Plataforma, which is in Brazil.

Danish: I hear that you tend to travel between Brazil and Poland a lot. Why all the travelling if the company is in Brazil?

José: I have a company called Plataforma Tec in Brazil. We are basically a Ruby on Rails consultancy. We do coaching, training and we develop web applications. In theory I should be there, because my work is there. But it happened that I got married to a Polish girl, so I spend most of my time in Poland and it happens that sometimes I’m travelling between these two countries.

Danish: You should convince her to come to Brazil, it’s nice and warm there.

José: Yes, I’m struggling with the cold, right now it’s probably minus ten degrees Celsius outside. But both places are fun, so I’ll try to get the best of each.

Danish: From what I’ve heard from Yehuda, you got into doing some of the Rails core stuff through the Google Summer of Coding in 2009, so I’m wondering what motivated you to do Google Summer of Code and why did you decide to pick a Ruby on Rails project?

José: So I was already doing Ruby on Rails development, I was working on Rails applications at the end of 2006. So I was already interested in Rails and I was already doing some kind of open source development. I took a project called Inherited Resources, and I was also working on a project called Formtastic, for example. I was facing some issues because I was developing Rails applications and of course I wanted to use Inherited Resources to make my controllers cleaner and I wanted to use Formtastic for my views and I was using RSPEC. When I generate a scaffold for something, I want it to automatically use the Inherited Resources controllers, Formtastic views, to generate RSPEC tests. What happened was I could create a generator for Inherited Resources for the controller, I could create a generator for Formtastic for the views, and I already had the RSPEC, but they simply could not play along. For the generator, for each gem I had to create another gem that would just duplicate the code from these generators to do what I wanted. The generators just could not play along even though they are responsible for one part. So I was facing this problem and I was thinking about generating a tool that would fit my needs, and then I said “You know what? I think this should be fixed in Rails.” The Google Summer of Code project was coming, and I decided to submit a proposal.

Danish: How did the Google Summer of Code go? Was it a rewarding project to be able to do?

José: It was great. It wasn’t hard overall because I had already spent a lot of time thinking about how I was going to design it and how it should work. It helped me because that was when I met Yehuda, for example, and it also brought me a lot of visibility because at that time we were just four students. We had a lot of interest in our project and that led to further contribution in the future. So it was a very rewarding experience and it was really amazing.

Danish: You focused on rewriting the Rails generator. Why did you think this was an important part of adding to Rails 3?

José: I knew when I was writing my application for Summer of Code that it was going to be hard. I knew that I had to be convincing. On the application form, I wrote about how everyone was talking about Rails 3 being agnostic. What I wrote was, “How can you say that Rails 3 is going to be agnostic if the generators are not agnostic, if they don’t play along, if RSPEC needs to copy the whole scaffold code?” So that was my position, which I still believe is quite true. You can see how the problem with Rails 3 is really hard—for example Datamapper. You would also have to have a Datamapper scaffold. And if you want to use RSPEC and Datamapper you would have to have something like datamapperrspecscaffold which doesn’t make sense. So it’s important for us to have agnosticism and generators that are modular and they can play along with each other.

Danish: I looked at your github page and there are definitely a lot of projects you’ve worked on. How do you find all the time and what have you been working on lately?

José: One thing that helps me a lot is that I work from home. With the office being in Brazil, it would be hard to commute to work everyday. The benefit is that when I wake up, I’m in my workplace. Some people spend lots of time getting to work, taking showers—kidding—and I just don’t waste that time. I can work more hours per day, it’s easy for me to work ten or twelve hours per day. I think that I have been changing projects at a very good pace. For example, in 2009, I worked on Inherited Resources and Remarkable. This year it was mostly Rails, but I also started some very nice projects like Devise, which you probably know is a Rack authentication solution for Rails, and also Simple Form, which is kind of like Formtastic. So the flow of projects has been really good. I’m already working on new things for 2011. It’s a little bit bad, but I’m not working on any projects right now, so I have more free time. Since I am not working I decided to study. So I am studying all the things that I wanted but didn’t have the time to. I am studying Node.JS, Coffee Script, Erlang it’s been really fun. I think the best way to learn a new language is to try to build something with it. There is a project for Node.JS that is called Zombie.JS. It’s basically an integration tool for Node.JS to write integration tests. It’s cool because it’s very easy to have JavaScript integration since it’s easy to evaluate JavaScript. They say it’s fast, and I thought I should probably try to write a driver for it to use it for Rails. So that’s what I’m playing with right now. We have Capybara, which allows several drivers, and I’m writing a Capybara Zombie driver. We’ll see how it goes. It’s been a lot of fun for me because I am learning Coffee Script and some things were not working, so I took some time to read the specifications. I’m reading a lot and learning a lot of things, and I hope that in the coming year me and Plataforma are always releasing new open source projects.

Danish: So I know that you’re working on your first book, “Crafting Rails Applications.” In your blog post, you talked about how people say there’s just too much “magic” in Rails. How do you think that myth was created and do you think the Ruby community is doing a better job now of explaining the architecture and unveiling the “magic” of Rails.

José: If I could guess, I’d say that there are two parts to the magic. The one, which I think is really, really good, is that sensation that everyone gets when they come to Rails: “Whoa, this is wonderful, it’s so easy for me to do things.” So this is the good magic, in some sense, the sensation that we should never lose. I think that at some point, everyone wants to convert the sensation of everything being easy into understanding. They really want to understand what is happening. And I think the main reason the myth was created is that Rails, some time ago, didn’t have very good documentation. At the beginning the code wasn’t that modular and it was hard to understand. I think that in this process of converting that feeling of amazement to understanding, people simply resolve to say, “No, it’s magic,” because it is hard to understand what is happening. You didn’t know how the controller worked, how the views were rendered, how your applications initialize because it’s something complex. You just need to compare for example the file configs in Rails 3 and Rails 2.3 and you’ll see the difference. When you look at the file in Rails 2.3 you’ll say, “Oh my God, what is happening here?” and when you look at it in Rails 3 you’ll say, “Oh, I see what’s happening, it’s just setting up the load path.” What happens is that people don’t understand how it works and they just leave it at “magic.” The book is only possible because Rails 3 changed things a lot. We have a lot more documentation, the code’s much more modular, much easier to understand. The good side is that we can finally start to say, “See, it’s not magic, you can understand what’s happening here.” This is how an application initializes. This is how everything works. The target of the book is to allow people to understand how Rails works, and how that can make you write better applications. I think that this process is happening not because of the book but because of the Ruby on Rails community as a whole. If you look at the community two years ago, you can see that it’s improved a lot. Now everyone’s writing test. At the beginning, not all open source projects included tests. Now testing is very strong in the community. There’s a lot of discussion lately about Solid and how we can organize our code better. I think that the Ruby on Rails community is improving, and we’re doing a better job of explaining the architecture and saying it’s not magic, this is how it works. I think we’re going in a very good direction.

Danish: You’re a Rails Core team member. What was the process of becoming a core member like? What advice would you give to a developer who wants to become a core team member on an open source project that they’re passionate about?

José: My process about Rails was mostly how to make Rails 3 come out. I knew that was a huge milestone, and we had a lot of things to do. Basically I suggested things I could do, places I could improve, and they also needed help with some things, like the new Rails engines, and I put a lot of work in on that too. Eventually, with one contribution after another, I got commit access, and with commit access, I became a Rails Core team member. I think that if you want to collaborate on an open source project the best thing to do is to put what you need inside the project and try to make it better, because you are driven by a need. You need it for your applications, or you need it for your day-to-day development.

Danish: You’ve spoken at a lot of conferences. What advice would you give to new developers who want to be able to speak at Rails conferences? What topics would be useful for them to look into? What process should they use to write a good proposal and give a talk?

José: The most important step is to find something that you really like, and something that you really want to study and that you’re confident talking about. My first talks were not in really big conferences. I started talking at small meetings. For example, one of my first talks was at the Krakow Ruby User group. It was very small audience. It was about Remarkable, an open source project that I was working on. I was fairly comfortable talking about it, so I thought, why not? That’s usually how I works. Just choose something that you really like. You just need to find something that you like and you want to know more about. Study it and get comfortable talking about it.