Episode 103 of The SitePoint Podcast is now available! This week Louis Simoneau (@rssaddict) chats with Peter Cooper (@peterc) and Jason Seifer (@jseifer) of The Ruby Show about the latest goings on in the Ruby universe. We talk about Rails 3.0, Ruby beyond Rails, and the immortal question of whether or not Rails can scale.
Listen in your Browser
Play this episode directly in your browser! Just click the orange “play” button below:
Download this Episode
You can also download this episode as a standalone MP3 file. Here’s the link:
- SitePoint Podcast #103: Ruby is Old Enough to Drink with Peter Cooper and Jason Seifer (MP3, 50:38, 48.6MB)
Subscribe to the Podcast
The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.
Links Mentioned in this Episode
- The Ruby Show
- JRuby
- MonkeyBars
- Rubinius
- Alioth Shootout Benchmarks
- Phusion Passenger
- Heroku
- Why’s Poignant Guide to Ruby
Interview Transcript
Louis: So, with us today on the Podcast are Peter Cooper and Jason Seifer. Hi Peter.
Peter: Hi there, how’s it going?
Louis: Very well. Hi Jason.
Jason: Hello, how are you?
Louis: I’m very well, how are you?
Jason: I’m doing very well.
Louis: Alright, well, Peter and Jason are current hosts of The Ruby Show which is a podcast about all things Ruby, so I thought we’d have them on the show today just to talk about where Ruby’s at, what’s going on in the Ruby community, how Ruby on Rails is developing; version 3 of the framework was released fairly recently so it’s I thought a good opportunity to have an update from the Ruby Community to our listeners, who some of you might be into Ruby but a lot of you aren’t so just to see where things are at. But before we dive into that do you guys want to give me just a bit of background on yourselves, how you got into it, how you got into Ruby, how you started podcasting, what you’re doing at the moment; so, Peter?
Peter: Yeah, I’ve been pretty much programming ever since my dad sort of used to give me hand me downs in the 80’s with the old Micro computers we had in the UK at the time in the early 80’s which the main one was a machine called the BBC Micro which I don’t think ever made it out of the UK much but it was sort of a really big deal here, so I learned to play around with that and program and so on at a really early age, and I sort of, you know, it was just something that was always a hobby of mine growing up with Basic and then C, then Pasquale, I sort of went back to front; I kind of went with C and then I started just moving down and down the chain. And then I did Perl for about eight years which I think probably drove me to the brink of suicide before Ruby came along (laughter). In, yeah, about 2004 I got on board with Ruby and I didn’t really want to jump on board at first because programming had become a little bit perhaps negative to me by that point, but it totally sucked me in and totally won me over and I’ve really enjoyed it ever since. And in terms of the podcasting it’s definitely not something that’s ever really been on my radar as anything to do as a serious pursuit, but then in the last year or so I’ve known people that have gotten involved, it seemed interesting doing interviews like this and then the opportunity came up to work with Jason on The Ruby Show and so I just — we’ve always got on well so it seemed like a good opportunity for a bit of community, not community, a bit of comedy in the old Ruby scene so I had to jump at it.
Louis: Alright, that’s good. How about you Jason?
Jason: Similar story to Peter’s, I’ve been programming my entire life, I started when I was about six years old, although sort of the opposite, I started with Basic just sort of watching my dad do some programming and then as time went on I moved on to PHP, wrote a bunch of Perl, was able to read practically none of it (laughter), and then probably right before Ruby on Rails 1.0 was released I started getting really into Rails and then doing consulting for web development with Rails and been there ever since.
Louis: Right. So, I guess the next thing I just wanted to talk about briefly for our audience, let’s say for someone who’s maybe heard of Ruby or heard of Ruby on Rails can you give us just a rundown of why is Ruby special, what drew you to it and what’s so exciting about Rails and why is that something that you guys have both gotten involved in?
Jason: Peter, do you want to go first?
Peter: Yeah, I’ll take the Ruby end of things and then I’ll let Jason perhaps dig a bit more into the Rails side of things. Yeah, the thing about Ruby that I really like about it is the, and people refer to it as a pure object oriented language, I wouldn’t say it’s 100% pure but it’s pretty darn close compared to the other languages I’ve used. And what this essentially means is that almost everything that you have in Ruby, any type of data or even kind of things like you just type a number in you can call methods on it, so everything kind of acts like an object. Yeah, I mean that’s just appealing from the oft because you don’t ever have this, you don’t have a significant ambiguity, and whether you call a method on something or whether you have a function or whatever like you would in Python, for example, in Ruby you can just take a string and you can just ask it its length, you just do everything through that method interface and that’s really appealing to me. And the reason for that is because the background to Ruby, and the guy who created it is called Yukihiro Matsumoto, but we all know him as Matz; he started out in 1993 and he was a bit kind of bored with some of the languages he was working with and wanted to make something that I think he used the word ‘joy’, he wanted it to be fun to use, something that he would find really enjoying to use. So he came up with some ideas with some other people, came up with the name of Ruby sort of based on Perl’s success but would move up the alphabet, and so he’s always been keen on that it’s got to be joyous, it’s got to be enjoyable, but also he believes in something called the principle of least surprise, so if you read a piece of code it should be reasonably obvious what it does. Now, that’s definitely not true of Perl as both I and Jason have both said, but you can actually do so much with Ruby because it’s very dynamic and flexible, you can rewrite how things in Ruby kind of work almost internally, so you can actually override like the addition function, addition method rather, on integers or whatever and have it so that the way that numbers are added together totally changes, so you can actually screw around with Ruby in that way as well. But, in the main if you follow the conventions, and Rubyists are very big on following conventions and best practices, if you follow these then most Ruby code is very easy on the eye, very easy to read, and that’s something that really appealed to me coming from Perl where even your own code can be unintelligible within weeks.
Louis: Yeah. So Ruby sort of was developed as this sort of scripting language that was like you said meant to be joyful and really object oriented, and then I guess something happened where suddenly people started using it on the Web and I guess Ruby on Rails was probably the biggest driver of that. So, Jason, you want to just give people a bit of background on Rails; I know a lot of people are probably quite familiar with at least the idea behind Rails because it’s inspired a lot of frameworks in other languages, so in PHP, there’s CakePHP which is very closely related to Rails, but maybe just give a quick bit of background about how that came about and why you think Rails is the bees knees.
Jason: So, before Rails was released there’s definitely a lot of web development going on, I mean the Internet transformed to rich internet applications, lots of web development; before Rails there was a lot of ceremony and things that needed to be redone several times when starting a new application. So, Rails comes along and says, hey, there’s a lot of stuff that we do a lot of the time, we can package this up, make it easier to use, take a lot of the ceremony out of writing a web application, so things that used to take a long time to get set up, well, that’s largely done for you; instead of having a lot of configurations in a Java application it would have a lot of convention.
Louis: Things like mapping a set of URL’s to methods in your classes or just interacting with the database are things that in Rails you don’t even have to think about most of the time.
Jason: Exactly. You know a good example let’s say you want to — if you have a database table of books you can just call a class book and extend it from ActiveRecord and Ruby and Rails will do a lot for you around that, give you a whole bunch of very simple ways to query the database, and I mean object relational mappers weren’t new but Rails made it very, very easy to jump in, get started and be productive.
Louis: Alright, so now let’s talk a bit about Rails 3. I guess there are probably a lot of people out there listening who are familiar with Rails, familiar with this whole idea of among other things object relational mapping and all of the things that Rails and other web development frameworks make possible but maybe only quickly glanced at when there was a new release; if you’re not actively using Rails it’s not something, you know, I don’t notice when there’s a new release of Django so I don’t know what’s new. So maybe just let’s have a chat about what’s new in Rails 3 and why — I mean it looks like a pretty major release from everything I’ve seen so maybe you can talk a bit about that.
Peter: I guess Jason probably knows a lot more about some of the day-to-day issues with it, but just one thing I wanted to cover first was that Rails 3 was almost kind of an entire rewrite in a sense, you know, Yehuda Katz was the main driver behind it, it came from kind of the Rails-Merb merger as it was called, but it wasn’t so much a merger, it was more like let’s take Yehuda and some of the people that worked on Merb and implement some of their ideas on how to build a web framework as they did with the Merb.
Louis: Just a bit of background, Merb is another Ruby web framework.
Peter: It is and it was but it’s not so significant now in the sense that it was kind of merged into Rails, but there is still a separate build of Merb out there but it’s not particularly popular, it’s sort of been kept for maintenance reasons really. But they did this kind of merge and it brought Yehuda Katz and some other people on board, and he kind of took a lot of the modularity that was in Merb and baked it into Rails from the ground up, so that involved rewriting a lot of the core stuff, like the routing system changed and there’s all these tiny things that are inside Rails but they all had to be changed in significant ways to deal with this modularity, and it’s a real surprise actually that he managed to coordinate and pull it off so well, but pull it off he did and we’ve got Rails 3 now, but Rails 3 really is, you know, a lot of the API looks very similar on the surface but under the hood it’s almost an entirely new thing.
Jason: And that’s something that’s really surprising when you actually get to use it and code a Rails application. As an example the previous version of Rails, Rails 2, there’s very minimum rewriting that you’re gonna have to do upgrading a Rails 2 to Rails 3 because as Peter said the API is largely extremely similar, so I mean like I’ve ported a couple applications and it could be anywhere from four hours to a day of work, not really as bad as you think for what’s essentially a rewrite of an entire framework. But with that said, one of the things like Peter was talking about Merb, and Merb was sort of a competing framework to Rails, but competing in the sense of it had different ideas about how to approach full stack web development, so where Rails would give you this whole gigantic skeleton and application, Merb gave you that option but let you break it up into different pieces, so you could say I don’t need the whole thing, just give me these few parts and I can build my application. Now, these days if you’re going to write a fresh application on Rails 3 it’ll give you everything you need to get going but you have the same option of choosing more modular parts of it.
Louis: Yeah, right. And so for someone who’s just say sitting on the outside looking at Rails 3, so you’ve got this modularity where could you give maybe just an example of the kind of thing that you might swap out for a different component if you were starting a Rails application; what types of things, like are there alternate modules that you use a lot of times in your development?
Jason: Yeah, so a good example is there’s a testing framework that a lot of people use, Rails comes bundled with test unit but the Ruby community is pretty big on testing, and there’s a new testing framework released about every three and a half to four weeks, and you can pretty easily swap those out. Another thing, the default ORM is called Active Record, and if you want to choose something like MongoDB you can easily drop in something like Mongo Mapper to talk to MongoDB right out of the box and Rails will adjust very easily to it.
Louis: This is something that was I guess possible with previous versions of Rails, a lot of people were using RSpec with Rails 2, but what you’re saying is that Rails 3 has just made that modularity sort of more built in so that it’s really designed to allow you to take out any component that you don’t like and replace it with another component that you prefer.
Jason: Exactly.
Louis: You were saying okay so the Rails community is big on testing and there’s a new testing framework released every three and a half to four weeks, now you might’ve been joking a little bit about that number, but I do get that impression from the Rails community is that all of a sudden, oh, we’re doing everything this way now. So it can be a little intimidating whereas before if you looked at Rails back in the early days of Rails 1 and Rails 2 you come to it, oh, this is how we do things in Rails, this is how you build a sample application, really straightforward, go ahead and learn it and build your applications. Nowadays it seems like the community’s grown a lot and everybody has their very specific ways that they like to do things, so it can be intimidating for someone who’s coming at it from the outside. What would be your suggestions for someone if someone wanted to start developing in Rails and is getting this feeling that, oh, everyone in the community has different ideas about how I should be doing everything, so how do I go about finding what the best way to do one thing is or really get up and running with Rails.
Jason: Well, Rails comes with a lot of built in defaults that you can get hit the ground running and just start, you know, use the Rails defaults and boom you’re good to go. There’s a lot of great documentation up on the Rails Guides site.
Louis: Yeah, I saw that, that was a really tremendous documentation effort going from what it was before; I find the Rails Guides is some of the documentation out there.
Jason: They did a tremendous job with that, but yeah, I mean that will walk you through everything that you need to make a Rails application, and then once you get more into it you can read more and kind of make your own decisions about what you want to use, but that’s sort of why Rails gives you at least some good defaults to go to, I mean you’re not gonna start Rails and say, hey, I have no idea what to do, I can’t work, like there’s some good things chosen for you, by default you get Active Record, you get test unit and I believe the default that comes with Rails as far as a JavaScript library is Prototype these days but you can definitely get started.
Louis: So is Rails still using Prototype as the default?
Jason: Yeah.
Louis: Alright, that’s really interesting because I don’t think — that’s I guess an interesting choice because a lot of people have started using jQuery a lot more as you know in the past say two years, so what do you think prompted the decision, is it because the Rails community is so familiar with this particular library?
Jason: I think it was probably just a backwards compatibility idea, you can I mean in about two seconds drop in jQuery and it’s ready to go right out of the box.
Louis: Yeah.
Peter: Yeah, I guess one of the things that I just wanted to bring up, actually there are sort of a couple of things you want to circle around which is sort of how people that are listening to this if they’re not into Ruby already how they might want to get started with it, obviously that’s quite important and how to sort of keep up to date with what’s going on in the world of Ruby. But I just wanted to touch on the different implementations that are around because this wasn’t really such a big deal a few years ago but now there are different production viable ways to actually run and deploy Ruby code. So there’s sort of the core that’s sort of the defacto official sort of, in air quotes, Ruby implementations which are called MRI which stands for Matz’ Ruby Implementation or Matz’ Ruby Interpreter, I can’t remember exactly what the I is for, but this is available in several varieties, well, the main ones are currently 1.8.7 which is sort of the slightly older version but people still use it because it’s good for sort of older app Rails 2 apps and a lot of the code that’s already out there, but then over the last year what’s become significant since its release in August is Ruby 1.9 or specifically Ruby 1.9.2 which came out in August, and this is a kind of a rewrite really with a much faster VM, the performance is a lot better, the memory use is better, and so on and so forth, and these are sort of the defacto official ones, they’re written in C, and they’re compiled for most of the platforms you can use them fine. But there’s also JRuby in the last couple of years has become fully production ready, runs on the Java JVM, it’s written in Java, you can interact with all of your different Java libraries, you can put together a swing app, there are several different libraries to make it easy, like Monkeybars for example, that’s a really good way to go as well; the memory use is a little bit high but in terms of being able to roll it out and trust it you can definitely do that. There are also a couple of others not quite so popular at the moment but there’s MacRuby which is aimed at, well, OS X, it gives you a better way of accessing some of the Mac frameworks.
Louis: So is that something for building desktop applications for the Mac?
Peter: It’s not specifically for that but it’s good for that; over the last year or so it’s become a good way of rolling out desktop applications on OS X, and I think you’re going to see a lot more of that in the next couple of years, especially with the Mac App Store. And sort of last but not least, I mean there are some others, but sort of last but not least in the primary ones is Rubinius, and this is essentially a Ruby implemented in Ruby, it’s not quite as obvious as that but there’s basically a very fast VM written in C++, and it’s really just the core stuff that needs to run, but then all of the main classes like Array and Hash and different data structures and so on are implemented in this kind of subset of Ruby on top of it so that if you’re a Rubyist you want to kind of help out and help and change the way that Ruby works you can do that with Rubinius, and I think you’re going to see that becoming a much bigger deal over the next couple of years, and it could eventually sort of usurp the MRI.
Louis: Yeah, you were just talking about Rubinius, so for the most part if someone wants to get started in Ruby would it be correct to say that sort of the mainstream like the core Ruby implementation, the basic one is the one to go with?
Peter: Yes.
Louis: Or are there good reasons to go for something like Rubinius?
Peter: No, right now MRI pretty much all the way, it might be a slightly contentious thing to say, but I can’t see any reason why you’d want to go with anything else unless you were like heavily into Java in which case you might want to start with JRuby so you can use your existing tools.
Louis: We talked a little bit earlier about testing, you were saying that that’s a big thing in the Ruby community, but maybe talk a bit more about that because it’s becoming more I guess the norm for web developers whereas if you look several years ago I guess PHP was a bit of a hobbyist kind of thing so people weren’t writing a lot of tests, and now that’s really become even the norm for something like PHP but Ruby has had that mindset pretty much from the beginning. So, what is it you think about, is it something specific to the community or is it something specific to the language; what is it that’s made it so focused around testing, you know, the things that define the Ruby community that even when you think about it you know that a Ruby person is kind of a different kind of programmer, what is it that you think has driven that?
Jason: I’m not really sure what the drive towards testing is with the Ruby community but it’s really ingrained, I mean even to the point where a lot of the tutorials these days that you see coming out on blogs and things like that will walk you through test driven development with Ruby. But I think this is more of a symptom in general of just development kind of growing up and saying this is what we do rather than where a while ago it was sort of optional to write tests, it’s like it’s so easy these days no matter what language you’re using to find a testing framework and use a testing framework that more often than not it makes more sense to test rather than not to test. I think something that contributes to it with Ruby is the fact that Ruby is so open and you can get in there and you can do anything to pretty much any Ruby class. So if you’re in there changing like Peter said earlier you can change the way the addition operator works in certain classes; if you’re doing that and not having a test for it to say what it does, some other programmer on your team is gonna jump in there and they might have no idea why something like that’s happening, but if you have a good test suite and somebody messes with something else then you’ll know a lot earlier in the process rather than later which is where you want to know.
Louis: Right. Is there anything else that’s been going on in the Ruby world, I guess that’s one of the things I’m interested in talking about here is for people who sort of see it from the sidelines, what have been the major developments, other than the release of Rails 3.0, in the last year or so?
Peter: Yeah, I mean there’s been quite a lot actually happen over the last year, I mean every year seems to be busy for Ruby in one way or another, but in the last year of course we’ve had Rails 3 but that’s just one of many things, and I think the biggest thing just in Ruby as a whole has been the release of Ruby 1.9.2 which I know it sounds only like a point release but it’s kind of like the first reliable full kind of production quality version of Ruby 1.9 that’s been made available and that you can actually rely upon and that people have actually been switching to. So Rails 3, one of the big things about Rails 3 is that it runs perfectly and smoothly on Ruby 1.9.2 which lets developers move up to 1.9 with its typically better performance and there’s been sort of a lot of enhancements under the hood, enhancements to the VM and some language enhancements as well, it lets people move up to that latest technology across the board so you can run Ruby 1.9, you can run Rails 3, and that’s literally all happened within not even the last year like within the last six months essentially, so there’s been that. But other than that there have been kind of strides made with these other implementations, like I say, there have been some significant releases of JRuby that have just made it faster and more performant; Rubinius is now some people would say a full production quality, I’m not 100% sure of that yet but I haven’t really played with it enough yet, and the same also goes for MacRuby, that whole idea of being able to build a whole Mac app with MacRuby; it was possible over a year ago but it wasn’t something you’d necessarily want to rely on whereas now it’s quite trustworthy. So, I think the biggest things that have happened in the last year aren’t necessarily just sort of releases of certain libraries and stuff like that, it’s really just a maturation of the implementations and of course some of the projects like Rails, but a maturation of like the whole base that its formed on, it’s a lot easier to deploy, it’s a lot easier to host, things are a lot more reliable, and I think that’s been sort of the hallmark of 2010.
Louis: Right, well that’s obviously good for someone who’s maybe considering moving into Ruby right now. You talked a bit about performance in there, I want to maybe touch on that really quickly because that was one of the complaints that you often heard from developers coming from other languages into Ruby was that it just wasn’t as fast as what they’re used to. Can you maybe address that and talk to it, because I know that the later releases, Ruby 1.9 for instance are a lot faster, but maybe just talk about that in general and how performance has changed and how it matters and how in the Ruby space how people deal with that.
Peter: I think actually it was before; what I’ll do is I’ll go over the Ruby side and I’ll let Jason go with the Rails side because there are important considerations on both. But with Ruby the historical kind of perspective and kind of the reputation it’s got has been Ruby, oh Ruby’s the slow language, but obviously that doesn’t take into account the amount of time it takes to develop say a Ruby script as compared to anything else. It is a very quick language to develop in even if in the past some of the implementations have been quite slow when compared against other languages like Python and Perl and so forth. But the work that’s been done with Ruby 1.9 and especially with JRuby which has just in time compilation so your script will actually get faster and faster as it goes along and perfects that compilation angle, those things have actually kind of brought Ruby up into the correct band of performance really for those type of languages, so if you look at the popular Alioth Shootout benchmark suites that post tons and tons of different benchmarks for each language online and you look at the results now the JRuby benchmark test actually have a lower, sorry, rather kind of like a — in terms of the time it takes to run the test has a lower median score than PHP, so it’s actually on a median average a little bit faster. And that’s pretty good because there’s only so fast that you can go without compromising on how easy it is to develop in a language, so obviously if you’re into C, if you’re into the languages that are at the top of the chart that’s great, but Ruby does give you a lot of cool stuff like this pure object orientation and the principle of least surprise and all this kind of overriding and making DSLs, all this kind of stuff, but now it’s giving it to you with an expected level of speed so it’s not totally dog slow like it used to be, it’s now more what you’re used to. But then Rails is connected to that of course because a lot or perhaps most developers are using Rails with Ruby, and so this also makes Rails a little bit faster, but Rails has also had its own issues with performance and particularly scalability over the years, and I know this is a scenario that Jason is dying to talk about. (laughter)
Louis: I mean maybe you can kind of give a bit background on the joke and why you’re chuckling about it before diving into it because some of our listeners might not be familiar with the background there.
Jason: Okay, for a really long time, for a while there was a long-running I don’t want to say joke, but it seemed like for a little while there were just a ton of blog posts being written on why Rails can’t scale and why people are sticking with PHP or Java for their web development needs, and I thought that this was pretty funny at the time because there were even at that point, and this is probably three maybe four years ago, probably closer to three, at the time there were still quite a lot of high traffic applications that were built on Rails and scaling just fine; I decided I would turn that into a bit of a joke in the Ruby community, and I registered CanRailsScale.com which I’m actually quite proud of; if you Google Can Rails Scale it is the number two result, at least in the U.S., and it’s just a web page that says “NO” (laughter). Oh wow, it’s number one now.
Louis: So you just tried to own that and turn it on its head.
Jason: Yeah, exactly.
Louis: So where do we stand at now? So you say maybe three years ago there were a few sort of high traffic Rails applications and sites out there, now there are quite a lot more.
Jason: Yeah, definitely.
Louis: What’s your view on where things stand now?
Jason: The same as it’s always been, you scale an architecture and scaling is application dependent rather than framework dependent. I don’t think much has changed and I’m still not aware of any frameworks that are gonna let you be “web scale,” as the kids say these days, right out of the box, you know it’s really something that’s application dependent, and each web application especially needs to scale differently and has different needs on how you’re going to approach that; there can be a lot of similarities but it’s not something that you should totally be relying on the framework for.
Louis: Yeah, okay. So, coming back that was a bit of a sidetrack off of we’re talking about changes in Rails and Ruby recently and you were saying a lot of the implementations have matured and things have gotten faster. One of the other things that’s interesting about Rails is I guess for someone who’s kind of learned a bit of web development PHP one of the initial things that made it appealing to students of web development initially is that you could write some PHP scripts, throw them on a shared hosting server and it came with PHP and MySQL and everything was pretty much configured for you. In the early days of Rails there was a significant amount of more server set up that was required to get your app up and running, so is that different now and if so how is it different?
Peter: Yes, significantly different. It’s something that really has changed in the last couple of years and for much the better, you know it used to be necessary to deploy a Ruby web app specifically or a Rails app kind of on its own daemon processes and have this kind of cluster of daemons running on a certain port and then set up your Apache or whatever it is you wanted to use to proxy through to those, or even just use like FastCGI was quite a popular way of deploying Rails apps around 2005, 2006, and it was a real mess, really unreliable, didn’t perform well, so on and so forth. But then I believe it was early 2008 a company called Phusion, or more accurately a couple of computer scientists who then became Phusion, released something called Passenger, at the time I believe it was just called mod_rails kind of after the Apache tradition of mod_whatever like mod_perl or whatever, and this came out it was an extension for Apache and what it basically did was it would spin up the Ruby processes in the background, it would manage them, housekeep them and proxy all the stuff through to them automatically, and it still runs in a similar way but it also works for Nginx as well now. And, yeah, you can pretty much now run any Ruby web app you like through like a Passenger, anywhere where there’s a Passenger module installed very simply, it’s not entirely as simple as PHP but it’s pretty darn close. And then there have been other services that have launched off the back of this kind of work in slightly different ways, but for like example the Heroku hosting service is quite popular, and this is sort of like a Cloud hosting service for Ruby web apps, and what you can do is if your managing your app with Git for example you can use Git to push your app up to the Heroku service and they will use Git to push your app up to the Heroku service and they will deploy and run it and make it available at certain URL all very simply, you know there’s like a base level service which is actually free to noodle around with your applications until they get to a certain size. So, you know, things have really changed massively in the last few years in terms of deployment and finally now you don’t have to sort of have a degree in being a sys admin or whatever to pull it off.
Louis: Right. That was my understanding of it. It’s interesting, I hadn’t heard that Passenger was capable of running under Nginx now as well, so that’s an interesting development for people who aren’t that interested in using Apache for things like this.
Peter: For sure.
Louis: Jason was there anything you wanted to add to that?
Jason: That was a great summary (laughter).
Louis: I was listening to it and I was thinking at some point Jason’s gonna jump in, and as it went on I’m like oh that has really covered everything I could conceivably want to ask about this, I don’t think we’re going to be able to go anywhere from that.
Jason: Yeah, I think the only thing that I would possibly touch on was that Heroku wound up being so awesome it’s like the idea is being copied for other frameworks as well.
Louis: Yeah, I’ve only very briefly seen Heroku, maybe you can expand a bit on that. So, what it is, is it’s a Cloud hosting service that’s sort of you pay by, similar to Amazon’s web services, you pay just for the processing power and the bandwidth that you use, but basically as you were saying takes care of all the deploying of the Rails apps, all you have to do is push up the source code and the rest gets taken care of, is that right?
Jason: Exactly.
Louis: And Peter was saying it’s free up to a point, what’s the cutoff?
Peter: Yeah, I’m not sure what the specific cutoff is, but it’s kind of based on the amount of like CPU and the amount of simultaneous connections.
Louis: So if you wanted to just write a demo app this is a great way to just throw it up on the Web so that you can interact with it in a live environment and it can be free, especially if it’s just a demo and no one’s using it.
Peter: Yeah, and it’s not even that expensive to scale it up. I mean Heroku does have some, you know there are some expensive parts to the service to add certain extra features on, but in terms of the basic service it’s not too cost prohibitive to scale, but then you know you can take what you’ve learned and then rollout your own VPS or use EC2 or whatever and then do it yourself from there on, and with things like Passenger it just makes it so easy to install, you can rollout your own thing easily as well if you don’t want to pay Heroku.
Jason: I was gonna say kind of another big thing with hosting that’s different than it was say a year, two years ago, is monitoring tools that we have for your applications which you didn’t have a few years ago, I’m talking about things like New Relic and Scout and this new one that the Phusion guys are coming out with that give you really the really fine grain metrics to a deployed application and let you see where you’re spending a lot of time in your requests; these are really nice tools to have.
Louis: Right. So it seems like the theme here if we go over what we’ve talked about, so Rails 3 has come out and that’s been de-coupled so you can use whatever different components you want, hosting has become easy, it’s become really cheap in some instances, so if you’re using Heroku you can use it for free up to a point, all the implementations are becoming very mature, there’s a lot of different implementations out there, and things are getting much, much faster. It seems like there has never been a better time to get into Ruby and Rails development.
Jason: I would agree with that.
Peter: No.
Louis: (Laughs) Peter is that no there’s never been a better time or no I disagree?
Peter: Well, actually it’s kind of a little bit of both actually because it’s a great time to get involved, there is a lot of work out there and there’s a lot of opportunities and people are still building their own web apps and it’s great even just for that. But then also on the flip side there some of these indices of how popular languages are sort of do show kind of perhaps the Ruby buzz, the idea of Ruby as being on the absolute cutting edge those days are sort of gradually waning in that respect. But I think that’s kind of a good thing in a way because it’s not necessarily people aren’t just running to Ruby now because oh wow it’s the latest fad or it’s the latest buzzword, they’re actually coming to it and seeing its strengths rather than sort of automatically fighting against it because they think it’s a fad. So, Ruby has reached this kind of maturation point which is funny really since Ruby has actually just turned as of last month has just turned 18 years old, so it’s reached maturity I would say by now and it’s not so much the fad that it was.
Louis: Right, so Ruby can drink now is what you’re saying.
Peter: Yeah, depending on what state you live in.
Louis: Alright, so let’s say if someone is listening and they were interested in learning Ruby and learning Rails what are the resources that you would recommend?
Jason: Definitely listen to The Ruby Show (laughter), every single episode we have on the site.
Peter: That is so true.
Louis: Never miss a show of The Ruby Show.
Jason: (Laughs) download that straight to the iPod. You know I saw the opportunity, I had to jump in.
Louis: That’s entirely fair.
Jason: No, there’s actually quite a few resources out there if you’re looking to get started, both with Ruby and with Rails, there’s a bunch of books, screencasts, podcasts, every single way you could possibly want to absorb information there’s a lot of availability out there. Did I mention The Ruby Show?
Louis: (Laughs) The Ruby Show, absolutely. I noticed one of the things that’s come out fairly recently is Rails for Zombies. Do you want to just quickly explain what Rails for Zombies is because I thought that was a pretty neat little way for someone to dive in.
Jason: Peter?
Peter: I just wanted to see what Jason was gonna say. Yeah, basically Rails for Zombies, and my look at it has only been sort of cursory, is that it’s basically a kind of an online training camp as it were for using some of the basic parts of Rails, so you can go in, you get to watch some screencasts which have been made by Greg Pollack and some of the other team at Envy Labs which is sort of a team of Rails developers, you can watch some screencasts, and then you actually kind of get this console in the web browser where it kind of gives you these little exercises like the Try Ruby online sort of Ruby interpreter, but let’s you do some sort of basic exercises with ActiveRecord and so on that you need to pass to sort of progress through the course, so it’s kind of an interesting interactive way of picking up a few of the basics. It’s not gonna be a substitute for a book or whatever, and it’s not a way of learning Ruby, it’s literally just an introduction to some of the concepts involved with Rails, but if you want to learn Ruby then you need to take another path. But just to get up to speed with some of the Rails basics it’s interesting especially with the zombies kind of makes it a very attractive way of getting into some of that stuff.
Louis: Right. So if you’re saying that people should already be a little bit familiar with Ruby, what would you say is the best way to just get up to speed with Ruby itself the language?
Peter: Well, there are a few different approaches, I mean if someone is totally new to programming or perhaps they just know a bit of HTML and CSS but aren’t too big on the kind of perhaps the logical side of some of these languages there’s a great book called Learn to Program by Chris Pine which focuses on Ruby. There’s also a book that I wrote and published with Apress called Beginning Ruby which is literally for anyone that has done some coding before so has a rough idea of what to do but kind of wants to have their hand held all the way through from basic adding numbers together through to building like a dungeon kind of game which is something we do in the book. But then you also have the higher end reference books as well like The Ruby Programming Language by David Flannigan and Matz, so Matz is actually involved in the creation of that book, that’s an absolutely excellent reference to Ruby 1.9. And then you also have something that’s called the Pickaxe, and this isn’t its official name because it’s got a picture of a Pickaxe on the cover, a book called Programming Ruby which is by Dave Thomas and several other people, I can’t remember all their names unfortunately, but that is also another popular book in the Ruby world. So those are some good books to start with.
Jason: There’s the also classic Why’s Poignant Guide to Ruby.
Louis: Is that still around? Is that still online somewhere because I think I tried to find it recently and I had a hard time finding it.
Jason: Yeah, you can definitely find copies of it if you Google Why’s Poignant Guide, now if you’re already — if say you’re a beginner with Ruby but not a beginning programmer, one book that I found that was really awesome is Design Patterns in Ruby by Russ Olsen, and that’s gonna take a bunch of the Gang of Four design patterns and show you how to implement them in Ruby.
Louis: Right. Alright, so that’s great. I guess the last thing I wanted to touch on is maybe have a quick overview of what’s out there; now that Ruby has become a more mature language whereas before the only reason why a lot of people would consider learning Ruby is to build web apps in Rails, now there are a number of other projects out there using Ruby, or different applications based on Ruby, do you want to talk a bit about Ruby outside of Rails and what’s going on in that world?
Peter: Yeah. There are actually other projects in the Web sphere, just to focus on that for a moment, like Sinatra for example is a popular alternative to Rails, it’s not like you can just take a Rails app and say okay I’m just going to re-implement all of this in Sinatra and it’s going to be like really easy, Sinatra does take a very different approach, it considers itself to basically be a library of tools for building really sort of web apps in a very lightweight way and in a very Rubyish way because you have literally take control of everything whereas Rails provides all these conventions and helpers, in Sinatra you’re kind of on your own, you need to develop everything, but that can also be a benefit, so if you’re trying to get like the absolute maximum performance or you’re doing something slightly unusual that wouldn’t fit into the Rails way of doing things, Sinatra is a great approach and that’s just had a new release I think yesterday, sorry, not yesterday, last week, so that’s quite interesting. And there are other systems as well like, well, there was actually one that was kind of like almost predated Rails as well called Nitro which I haven’t seen much of in the last few years but I believe that is still undergoing releases, and there’s also another one called Ramaze which has also been under active development recently. So there’s lots of little projects out there for playing around with web stuff specifically, but then outside of the Web stuff we sort of touched on MacRuby and the whole idea of making Mac apps, I also mentioned JRuby and the ability to create swing apps, so people have been doing that, it’s not like something that’s experimental or too cutting edge, if you do need to build a GUI based app that is totally possible with Ruby. But then perhaps like one of the things that I really like using Ruby for is for doing a lot of stuff behind the scenes for making like server processes that are perhaps for like messaging or for cuing or things that aren’t directly related to the Web or perhaps things that even you can call from the Web but aren’t actually typical HTTP services. So, for example, like the new HTML5 Web Socket stuff you can build the services kind of behind the scenes providing up all this Web Socket stuff and perhaps linking into a data store of some sort like a Redis or a Mongo or anything like that you can build the server process sort of end of that that your JavaScript will call in Ruby and run that separately, so you’re not actually serving your app up with it but you can still use it to control certain parts of an app. So there’s lots of things like that that are really fun, and it’s definitely become a good language for putting together stuff that runs in the background like that and services and daemons and things like that.
Louis: Jason do you have anything you wanted to add to that?
Jason: Yeah, I was gonna say I know a lot of people who use Capistrano for deployments outside of Rails, Capistrano is a gem that has another like a sort of predefined way of managing deployments for applications, and I know a bunch of people who use that on WordPress, along the same lines; you know we talked about testing frameworks before and I have friends who develop on WordPress and use Cucumber to test against WordPress install and things like that.
Louis: Alright, so do you want to just give a bit of background on what Cucumber is?
Jason: So Cucumber is an integration testing tool where you write your tests using this sort of plain text story language, and the idea behind it is that there’s gonna be more stakeholders than just the developer with an application, so people who maybe aren’t developers could actually get in there and write some stories and say hey this is how this certain aspect of a site’s behavior should work, everybody agrees on it and then you can actually take this plain text stories that people write and have them run against your application, against your live application and it will pass or fail.
Louis: Okay, so just a basic thing like “I want to be able to access all of my emails when I click on my emails.”
Jason: Exactly, and that’s very similar to how you would actually write the feature and then you would say something like “given I’m on the homepage when I press sign in and I enter proper credentials then I should see my emails.”
Louis: Okay, and then you write the backend to turn that into a test that will run directly.
Jason: Exactly.
Louis: Alright, so I think we can just about wrap things up guys, thanks so much for coming on the show and talking to me today.
Jason: Thanks for having us on.
Louis: We had a bit of an issue with Skype at the start but the last little while has been very good so hopefully we can edit that all together. Do you guys just want to just let us know where the listeners can find you guys online, let’s start with Peter?
Peter: Yeah, I’ll let Jason talk about the Podcast then, but I run what’s perhaps the most popular Ruby blog at RubyInside.com which is kind of articles and tips and stuff like that, but also run Rubyflow.com which is a community site where anyone can go on and post their Ruby on Rails related news and links and also Rubyweekly.com which is like a weekly newsletter of the latest articles and so on.
Louis: Alright, you’re very busy. So I’ll post links to all that stuff in the show notes; are you on Twitter?
Peter: Yep, I am @peterc on Twitter.
Louis: Okay. And Jason?
Jason: Did I already mention The Ruby Show (laughter).
Louis: I don’t think you did; I think now is the perfect time.
Jason: So we do a Ruby news podcast at Rubyshow.com, you can find me on Twitter @jseifer, my blog is Jasonseifer.com and I do Ruby on Rails consulting at Twistedmind.com.
Peter: Hint, hint (laughter).
Louis: Alright, thanks very much guys.
Peter: It’s been good.
Jason: Thank you for having us.
Louis: Alright, it’s been a pleasure. Bye.
Jason: Bye.
Peter: Bye.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Comments