RubyConf 2008

Conversations from RubyConf 2008. With Matt Aimonetti of Merb, Blake Mizerany of Sinatra, and Josh Peek of Rails.

Sponsor

Interviewed by Geoffrey Grosenbach

Transcript

Geoffrey: This is Geoffrey Grosenbach for Ruby on Rails podcast, November 2008. Last weekend was RubyConf in Florida, always a good time. Even though this is the Ruby on Rails podcast, I thought it was appropriate to talk to Matt Aimonetti of Merb which first released its 1.0 last weekend. Also, Blake Mizerany of Sinatra, and finally, Josh Peek of the Rails core team.

So Geoffrey Grosenbach here at RubyConf 2008 talking to Matt Amonetti, big drop today Merb 1.0. I bet you’re pretty excited about that?

Matt: Totally excited, I didn’t sleep so much but very excited.

Geoffrey: Now it seems like Merb has massively changed from the very first code that Ezra posted two years ago. Couple of lines, now it’s a full framework, and you guys have done a lot of work. What kind of things have happened even in the last six months with Merb to get it to 1.0?

Matt: So there was a big change between ‘05 and ‘09. There was a major redesign. What really happened in the last few months that’s major change, is that, we tried to make Merb more easier for people to get started. We wanted to be able to offer solution that is easy if you wanted to just get started and learn how to use Merb. And then if you don’t want, you can remove some of the components you don’t want, or you can add more if you want to.

You can also come up with your own stack and just decide what you want and package that.

Geoffrey: Do you think Merb is competitive with some of these smaller frameworks camping in Sinatra where you can have just a very small single file app, or is it better suited if you really trying to do more of a full featured app?

Matt: I think it’s great for both. So when you generate an app you can use the stack – the default generated app with generated for stack app. But you can use the Sinatra app which is just like a one file app for Merb, so if you do like Merb generates very flat, and then the name of the app you will have one file app. And you’re just going to get all the great stuff for Merb like router and all the nice things you get.

And then you can build on top of that. If you want to go from one file now or you want to add more stuff to it, you can also grow organically. So you can add more stuff.

Geoffrey: What are the big initial benefits of Merb – was being multi threaded, handling file uploads while also being able to handle extra requests, not locking up a longer process things like that – now Rails is going to have thread safety? Do you think the distinction of Merb is being lost with that or is Rails still missing on something’s that Merb can do because of having thread safety built in from the start?

Matt: It’s hard to answer this question. I think thread safety was dealt in a different way in Rails and Merb. When Merb was started thread safety was already an issue and we wanted to make sure it was working properly, and people Ezra and Yehudha worked on that.

So, since the beginning we knew we wanted to deal with thread safety, or Rails kind of added that on top of it. And stuff like action pack we have deal with it. It’s a different concept. You don’t have to use thread safety with Rails. With Merb everything comes free. I think the distinction is somewhere else.

Rails is great. And if Rails fits your needs you should keep on using Rails. We are not telling people switch to Merb. Merb is awesome in a different way. Merb is flexible. So if you need more stuff or if you need less stuff, Merb will really fit your needs. It’s also a clean rewrite. So we basically learn a lot from Rails. And we avoided making some of the mistakes. And we have like a clean slate.

So you get a different type of code. It’s also easier to go through the code. If you want to write plugin’s we have a nice API. So we have a public API and a private API. If you want to write extensions for the framework, we have slices so you can display content and reuse the code.

So you get a lot of stuff for free that you might not have with Rails.

Geoffrey: It’s a lot of work to get a 1.0 out, but also just the idea of “OK, when do we know it’s time to release the1.0?” You’ve already said “Well, as with any project it continues to be updated and maintained.” And even though Merb with the public and the private APIs you really want to keep backwards compatibility throughout. How did you decide “OK, we just need to do it 1.0, ” and what’s coming up?

Matt: Well the goal was 1.0 for a very long time. For us 1.0 had to have a public API and a private API. And we needed to be able to lock it in a way that we will be able to run the specs against this API until 2.0. And for that we needed to have proper specs. And that’s why we had to rewrite a lot of the specs to avoid all the marking and stubbing we were doing before.

We also wanted to make sure that 1.0 was easy enough for people to get started, because that was one of the main constraints with the previous version of Merb – it was hard to get started. If knew how everything was working it was fine but otherwise it was a bit challenging.

So 1.0 had to be a flexible release that had stable API and it was easy to use.

Dan: This is Dan Benjamin you are listening to the Ruby on Rails podcast.

Geoffrey: Geoffrey Grosenbach at RubyConf with Blake Mizerany, author of the Sinatra microframework also works for Heroku. So what’s Sinatra?

Blake: It’s a small micro framework for creating REST services.

Geoffrey: And the syntax looks a lot similar maybe what camping was to where you are really matching URLs to actions.

Blake: Right right. You map URL’s to a proc. So there is no idea of a router. Like everything is a route.

Geoffrey: And what kind of applications do you think people have been writing or what’s a great kind of application that you would say “Hey, this would be best if you use Sinatra to write it?”

Blake: I think web services is a really classic example of what I really intend Sinatra to be used for, it’s something really small. And it’s a back end service. It doesn’t have a user face in UI. But it’s meant to do things in the background and be able to take a high amount of traffic. I think that’s a really good example.

Geoffrey: Now speed was a priority for you. Do you have tests or benchmarks that you run regularly to say “OK, here’s my goal”? Or you just want to keep it small and whatever it does.

Blake: No, I just want to keep it small. I am not too much into the benchmarking. I like to test that while formatting new stuff, you know, into the routing, but just trying to keep the same numbers I have been getting. I don’t want it to really drop from that too much.

I never really intended it for it to be fast. It just became best because it’s too small. So that’s were I like it.

Geoffrey: Now it seems it was a big thing for many shared hosts to support rack through passenger so that then you can easily run a bunch of little Sinatra apps? Do you think the interest in Sinatra has increased since passenger became available and installed on different shared hosts or little places where people are just going to throw up a little app?

Blake: I mean those metrics I am not really tracking. But there is constant help and threads going on IRC and on the Google Group about passenger and using Sinatra with passenger. So, yeah, there’s quite a few people using it and there is some good help out there for it.

Geoffrey: Maybe unexpected but I know David Goodlad said he was actually using Sinatra running Ruby on a little Linux micro kernel on a little piece of embedded hardware. I thought that was pretty interesting. He is measuring temperatures from some boiler or something like that, and he was using Sinatra to drive that API.

Josh Peek: Oh, wow, no, I hadn’t heard about this. You’ll have to introduce me to him. [laughs]

Blake: Yeah, you’ll have to talk to him.

Josh: Yeah. Well, good stuff, thanks, Blake.

Blake: No problem, thanks a lot, man.

Jesse Newlan: [laughing] This is Jesse Newlan. You’re listening to the Ruby on Rails podcast.

Geoffrey: So, it’s Geoffrey Grosenbach, RubyConf 2008, driving away back to the airport, speaking a little bit with Josh Peek. Tried to hunt him down, but even with just a couple hundred people, it’s hard to see everybody.

So, what do you think? Your first time in a RubyConf, right?

Josh: Yeah, it was really great. Talks were a lot better than I thought, than RailsConf. Much smaller. So you get to definitely meet more people, I think. It was great.

Geoffrey: And you get a variety of obscure topics, embedded hardware… there is even a Ruby Kata, talking about using martial arts concepts to affect your code and things like that.

Josh: Yeah, that was pretty crazy. I don’t think… the most obscure one I went to was that Psychology in Ruby or whatever.

Geoffrey: Yeah, Philosophy… Aristotle and…

Josh: Philosophy in Ruby. Yeah, yeah. That was interesting.

Geoffrey: I gave a similar talk at Ruby Fringe in Toronto. No one asked any questions afterwards. Here, that was like half the talk was discussion of philosophy afterwards. They had to cut it off early.

[laughter]

Josh: That’s pretty funny.

Geoffrey: So, I don’t know if a lot of people know about you… you have quickly, but kind of silently risen to prominence in the Rails community, submitted a lot of code, won a couple of the monthly patch competitions a year ago or something. But you’re just starting college. You’re what, 19, 20?

Josh: I am 19 right now, and I’m a second year in college, so that’s sophomore. And I’m on the core team, I guess. I was officially inducted a few months ago, I guess, but I’ve had commit access for like half an year now, so…

Geoffrey: So, when you started hacking around with Rails, you probably couldn’t even drive.

Josh: ... I suppose. [laughs]

Geoffrey: But one of the things that you’ve recently done that a lot of people were excited about was making Rails thread-safe. That’s quite a lot of code to go over and try to implement that. How did you even start going about that?

Josh: Well, thankfully, Coz, who is my mentor, he helped me compile a huge list of things we needed to review and things we needed to double-check for synchronization, and stuff like that. So, it was a big project.

We started a little ahead on that big list, so we had a head start before the actual project started. So, all in all I think we spent maybe four months on it total. But it was on and off. It wasn’t a full-time thing.

Geoffrey: Yeah, some other young guys that also took on a big project were Hong Li and Nin of Fusion, who said that the first Apache module they ever wrote was Mod Rails, and now that’s a huge hit worldwide. Have you done other kind of thread safety stuff, or were you cutting your teeth on it?

Josh: No, this is my first. I barely understood what a mutex was before I even started this. So, I definitely learned a lot about thread safety. I kind of didn’t want to do the project at first, but I got suckered into it at like the last minute. I registered the last day and that was one of the ideas that came up. So I was like, “Oh well, we’ll do that, we’ll see how that goes.”

Geoffrey: Now, that can be really nasty, tracking down thread-related bugs. Did you have to do special things in order to test that, or it was mostly just putting it out to the community for people to try it on their own apps and find whatever bugs were left?

Josh: We didn’t do too much aggressive testing where we actually tested it with Apache Benchmark and throw a bunch of… it was mainly just looking through the source code, and I had to understand what the problems were with thread safety and what variables have you synchronized in.

Also, we really wanted to run on JRuby. That was the big thing, and JRuby doesn’t have the interpreter lock like 1.9. So even little tiny operations that you would think would be thread-safe, you still have to synchronize.

So even if you have a hash, and you’re using a hash like a big cache or whatever, you still have to synchronize that in JRuby because they don’t lock that. But in 1.9 it would probably work because of the interpreter lock for the native classes.

Geoffrey: And that’s where people are really going to be able to take advantage of it, because Java has more serious threads that can make use of that.

Josh: Yeah, I probably wouldn’t consider it being worth trying to convert your app over to anything else. Unless you’re deciding to run on JRuby, it’s probably not worth all the hassle to run on 1.9.

There’s probably some performance benefits, I’m not entirely sure at all. But we saw some—I mean, we just did some initial “hello world” benchmarks. They don’t really mean anything at this point, so I’m really curious to see someone put out a real JRuby threaded app with all… you know, and get some real benchmarks of performance.

Geoffrey: When I think of threads, I think of asynchronous jobs. We’ve got all these queue plugins… background job, delayed job, Beanstalk, Starling, all these things. Do you think there’s any room for someone to write a plugin that would take advantage now of the thread capability to write a lightweight background queue, or should that always just be something separate if people need to do that?

Josh: Oh, definitely. I think Merb does have the defer text.

Geoffrey: I love that.

Josh: I kind of want to see that in Rails, so that’s the reason we have the plugins, because Rails wasn’t thread-safe, so you can technically spawn a thread in the background and run those processes. So, it definitely would be cool if someone made a plugin that fit nicely and then we played around with it, you know. I think it’s something worth including in core.

Geoffrey: Now you have had a lot of advantage, being able to get mentored by Koz, respected developer. You’re doing some work for 37 Signals—hopefully that’s not secret.

Josh: No. [laughs]

Geoffrey: What would you—you obviously taught yourself quite a bit to get to this point. For people of any age who want to really get into Rails or just really understanding Ruby, what kind of things do you look back and say, “Hey, here are things that I really did to spend time programming or learn specific concepts”? Do you have any advice?

Josh: Well, I pretty much made the jump from… I was never really interested in programming… maybe four years ago, I was doing HTML, CSS stuff. And then I kind of dabbled in PHP. I didn’t know how to program, I just kind of copied snippets around. And Rails was sort of a buzz around that time. So I picked it up from there. Then figured that I probably should learn how to program, makes sense I should learn Ruby.

So after that I got the… which book? I think I got the Pickaxe book, but I really like the Chris Pine, Learn to Program.

Geoffrey: Chris Pine! Yes.

Josh: It’s a really short book but it’s really great if you’ve never learned how to program before. It’s really great.

Geoffrey: Oh, cool, I’ll go read that and then I’ll be able to write thread safety mutex, available semaphore, tossing around type of applications.

Josh: Yeah.

Geoffrey: PeepCode is having a sale this month. Get 20 bucks off the unlimited plan that gives you access to all PeepCode content for a year or one free credit with a five-pack. New content on CouchDB, XMPP, Jabber, Sphinx, Unobtrusive Prototype, and Merb.